XML is rapidly becoming of the 'hottest things since sliced bread'
(in this USA resident's vernacular).  For instance, Microsoft is
basing its next generation Internet strategy on a set of technologies
with XML at their core.

    Many XML standards also make reference to ISO 8601 date and time
formats.  As such, XML currently represents perhaps the most most
promising avenue through which ISO 8601 formats might become widely
used worldwide on a day-to-day basis for storage, programming, and
display of dates and times, as opposed to merely being formally
adopted by standards bodies.

    I recently wrote to the editors of O'Reilly's widely-visited XML
portal Web site, XML.com <URL:http://www.xml.com/>, asking whether
they might be interested in publishing an introductory article on ISO
8601 for the XML community:

>    Would you be open to the idea of publishing an article, on XML.com
>or in another appropriate O'Reilly online publication, on ISO 8601,
>the International time and date standard which seems to often be
>incorporated these days into various XML-related standards?  As just
>one example, the XML Schema candidate recommendation uses ISO
>8601-style dates and times for its date-related datatypes.
>
>    If so, I'll ask around on eGroups' ISO 8601-related list, in which
>I'm a participant, to see if anyone there might be interested in
>preparing an article draft for XML.com.  There are several long-time
>advocates of this standard who might be interested in introducing
>this standard and describing the benefits of its use to the large
>and rapidly growing XML community.

    Today, XML.com's editor, Edd Dumbill, replied:

>Yes, I'd definitely be interested in an article on ISO 8601.   An
>abstract would be a good starting point.

    So ... would you be interested in volunteering to write (or
collaborate on the writing of) this abstract, then an article?

    I'd be pleased to hand off this endeavor to anyone who wishes to
shepherd it to completion, but would also be very willing to help
coordinate and/or co-author.  In other words, I'd like to see this
happen and am offering time and effort to help ensure that it does.

Best wishes,

Aron Roberts  Workstation Software Support Group . 221 Evans Hall
                University of California, Berkeley, CA 94720-3808 USA
                aron@... . +1 510-642-5974 . fax 510-643-5385

[2001-Jan-05]



Another nomination for the ISO 8601 Hall of Fame.

This time, an American site that is doing it right. In fact this site is set
in a small corner of NASA. Perhaps even more surprising.

See:  <http://umbra.nascom.nasa.gov/eit/eit_full_res.html> and most of the
rest of the site centred around:  <http://umbra.nascom.nasa.gov/>.

Images are captioned with dates like '2000-12-31' (or '2000/12/31') or
'2000-Dec-31', and the text contains dates written in the form '2000 Dec 31'
or '2000 December 31'.

The writer of most of that Web Site tells me that:

>      Our usage of the ASCII time format stems from the CCSDS
> specification for ancillary data,
>
>      http://www.ccsds.org/documents/text/CCSDS-301.0-B-2.txt

which encourages the use of several date formats that are close to, or
subsets of, those defined by the ISO 8601 standard. These standards have
been in place within NASA for at least 10 years. Unhappily the CCSDS Web
Site does not itself make use of these simple date formats, though I have
presented a good argument yesterday why they should now consider doing so.
The writer of the Umbra/EIT Site also said:

>      As for the "big-endian" (year/month/day) order, the uniformity is
> probably an expression of personal preference (I've always thought it
> illogical to lead with the least significant bit of information in a
> date or address, and have always preferred the Russian way of listing
> country, town, street, and name [in that order] in addresses).


Maybe this small corner of NASA can be used as a good example in order to
get some of the more well known NASA centres to start using these formats on
their Web sites, and in their documents in the future.

We can try!



Cheers,

Ian.


<g1smd@...>


<http://www.qsl.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2001-01-05]

.end

Poking around the NPL's website I discovered a page advertising their
new "Phoneclock" clock-synchronisation software
(<http://www.npl.co.uk/npl/ctm/truetime.html> if anyone's
interested). It shows the release date (of the current beta) as
"10/12/2000". NPL really ought to know better, so I've sent their
webmaster a little note (below). I'll inform the list if there is any
response.

.. FB

> Your "Computer time services" page
> <http://www.npl.co.uk/npl/ctm/truetime.html> shows the release> date of
"PhoneClock" as "12/10/2000". How about using the
> unambiguous BS EN 28601 format, 2000-10-12 (or maybe it's
> 2000-12-10?), as described on your "Standard representation" page
> <http://www.npl.co.uk/npl/ctm/time_rep.html>?
> ;->

To all,

This message went to BE Inc. They did not bother to answer. That says
enough: BE Inc. wants this trash to be adopted globally. I have de-installed
BEos because of what can be read below and also because it does not support
my graphics card,

Han

Sir,

I have installed BEos, and I am irritated because this OS only has American
time and date formats like the AM/PM clock and the format MM-DD-YYYY.
I regard these formats as irrational leftovers of the Dark Ages, I do  not
want to have any truck with them, and I suspect that your company is
attempting to
impose them on the entire world.

BE Inc. knows very well that these formats are not used outside the US. Why
won't BE Inc. allow for a choice between them and the ISO 8601 standard
which uses YYYY-MM-DD and the 24 hour clock? At least Windows and the Apple
OS allow for the use of international settings. The Amiga's Workbench also
allowed people to make their own choice in this matter. The first thing I do
when installing an OS is
this: I throw these American settings away. But BEos does not allow me to do
that and that irks me.

Please stop trying to impose these outdated settings on the world and make
international date and time formats available in BEos. IBM tried to spread
the US formats world-wide in the MS-DOS era and failed. The world will never
adopt AM/PM and the curious sequence of month-day-year, just because the
USA is addicted to these formats.

Yours,

H. Maenen, The Netherlands

[2001-Jan-14]




A few days ago, while in Bournemouth, Dorset, UK, I visited the local
'Borders' bookshop, which is absolutely huge. They must have millions of
books in stock. There must be many thousands in just the computer section alone.


I had a look at very many computer books to see if any of them contained any
reference to the ISO 8601 standard at all. I was extremely disappointed.

Internet Standards and Protocols. Dilip Naik. Microsoft Press:  No mention
of ISO 8601 anywhere within the book. A huge omission.

Most (just about all, in fact) other 'general' computer books also made no
mention of it. A few made mention of ISO, the organisation, but most wrongly
called it 'The International Standards Organisation', when the correct title
is the 'International Organisation for Standardisation'. Another case of the
author just guessing, rather than actually looking at the ISO Web Site which
is easily found at:  <http://www.iso.ch/>.

Professional WAP, was a book that mentioned the Year-Month-Day date format
on Page 95, but then failed to use it in any of the examples shown on Pages
183 to 187, where it could have been used to very good effect. Another
missed opportunity.

I had a look in the index at the back of many of the books. Many of them did
mention some selected ISO standards. However this was usually ISO 646, ISO
8859, or ISO 10646, and perhaps a few others. The ISO 8601 standard was not
mentioned in the index of any of the books that I looked at; not a single
one. It is interesting to note that the vast majority of the Internet
related books also failed to mention standards such as ISO 3166 which is the
one that defines the two-letter country codes that ultimately make email and
Web Site addresses work.


There were several dozen books under the heading of XML. Almost every one of
these had no mention of ISO 8601 within. Many of them contained no
information about date formatting under XML. This is really bad.

Several books gave some programming examples, but using date formats other
than ISO 8601, usually using only the American 'mm/dd/yy' date format (but,
then again, a couple of years back, several books that were supposed to help
people with their Year 2000 Problem had all their example program codes
using only two digit years, and of course they still failed at (20)00-01-01
!!!).

One book gave some date examples (like '07/01/00'), and then warned the user
that it may be possible to misread this date, because in the US 'mm/dd/yy'
is used, and in Europe it is 'dd/mm/yy'. No mention was made of the
Year-Month-Day date format, the ISO 8601 standard itself, nor were any of
the date examples in the correct format. What a major chance to write some
useful paragraphs in that book? A totally wasted opportunity.

Building Web Sites with XML. Michael Floyd. This mentions ISO 8601 on Page
78 and then immediately spoils it by quoting this example...
1999-6-29T08:06:22+4:0   - spot the three mistakes (all of the same type).
Almost, but not quite. Oh dear.

XML - The Annotated Specification. Bob DuCharme. Does not mention ISO 8601,
or Date and Time at all. About the same level as all the other books on XML
that I looked at; way over 50 I guess. Bad.

Only about three books correctly gave a date example using the ISO 8601
format, but they then failed to actually mention the ISO 8601 standard
itself, failed to mention why the date needs to be written that way, and
then also failed to mention what the example date actually means
(Year-Month-Day-Hour-Minute-Second). They just printed the date in the
format of '1999-07-22T15:08:22' within a programming example, without any
further explanation as to why it is done this way, or what it means.

Several books made reference to the GMT Time Zone, rather than to UTC which
has been used since 1971 (GMT and UTC are NOT the same thing... they are
close, to within 0.9 seconds, but they are emphatically not identical). Most
books didn't mention Time Zones at all. One said that GMT and UTC were
absolutely identical. Absolutely not! Ask any astronomer, or look at the
various Astronomy and Time FAQs available on the Internet.

XML Developers Handbook. Kurt Cagle. Sybex. This was the only book that I
saw do it completely right. This was out of at least 50 books that I looked
in. Even so, there was a lot more, that we all know as obvious, that could
have been said, but wasn't.


With XML as a new technology, and the ISO 8601 date format supposedly now a
part of the specification, it was horrifying to discover that over 95% of
books on the subject contained either none, or incorrect, information on the
subject. The people writing these books are trumpeted, often on the inside
front or back cover, as 'experts on the subject having been at XYZ
Corporation for over 25 years, and having written 50 books on computing
matters...  blah blah waffle waffle. If they cannot get it right, then what
hope have we of the people who read these books getting it right.

If we are thinking that we have it licked with XML, then the evidence in
print is very far from that scenario. A lot more work needs to be done to
promote Year-Month-Day working. Even many of the 'experts' on XML do not
seem to have heard of it, are not writing about it, and are not pushing the
idea out to their millions of readers.


Please can everyone on this mailing list, check out a few books in your
local bookstore, and start contacting these authors, so that they may put
the matter right. Let's go educate the 'experts'.




Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2001-01-14]

.end

To those who wish to contact Be.Inc about their non-standard date and
timesettings, here are two of their e-mail addesses:

USA and Pacific: info@...

Europe: infobe@...

Han

[2001-Jan-19]



Hi,
   I am aware that the mail server for all of my incoming mail at 'cwc.net'
failed around 2001-Jan-16 15:00 UTC.

I also believe that a service resembling normal operation was not restored
until around 2001-Jan-18 22:00 UTC.

At this time, a backlog of 8 messages was delivered, way below the number
expected. I already know that some messages that have been sent by other
people have not arrived here, and so these are presumed missing. I don't
know what else may be missing, hence this note.

My outgoing mail is currently routed via 'freeuk.net', and this service was
not affected. Everyone that I wrote to during this time, should have already
received all of the intended messages (unless you also use the 'cwc.net' or
'cwcom.net' service). My email address at work was also not affected.

If you sent a message to me between those dates above, and you have received
an error message from your ISP, then please send your message again.

If you recently wrote to me and you have not yet had a reply, then please
send your message again.

If your message is not listed below, and was sent after 2001-Jan-16 15:00
UTC, then please send your message again.

In all these cases, I will not have received the original copy. Please send
again.



The last message I received, before the problems started, was:
  wessex@egroups  2001-01-16 15:00 -0000  [WAS] Shuttle

The only messages delivered since service was resumed on 2001-01-18 are:
  wessex@egroups  2001-01-16 17:02 -0000  [WAS] Shuttle Launch
  wessex@egroups  2001-01-17 19:21 +0000  [WAS] Shuttle Cancelled
  wessex@egroups  2001-01-17 20:32 +0000  [WAS] SpaceGuard: Impact #12
  Dave Mills      2001-01-17 23:09  EST   Re: Date and Time the ISO 8601 way.
  Aron Roberts    2001-01-17 23:41 -0800  Expanding on the 'P.S.' in the ....
  wessex@egroups  2001-01-18 07:28 +0000  [WAS] Field Meeting Reminder
  ISO8601@egroups 2001-01-18 10:29 -0000  [ISO8601] Addresses of Be.Inc
  wessex@egroups  2001-01-18 11:43 -0000  [WAS] Mir
but due to spooling considerations the order was very jumbled up.



Aron Roberts:  I have the 'P.S.' message, but I do not appear to have the
original message, or any others. Please send again.


If in doubt. Send again... I would rather receive two copies of a messsage,
than none. However, if it was a 'group' email message, the originator should
send the new copy directly to me, rather than to the whole group again.




Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2001-01-19]

.end

To all,

Although I have set my Windows 98 computer to the
ISO 8601 standard, I still have the format
mm-dd-yyyy AM/PM lurking somewhere in my computer and it always pops up in
my e-mail headers. Just look at the header below. Does anybody know how to
get rid of this?

Thanks in advance,

Han

----- Original Message -----
From: "Han Maenen" <han.maenen@...>
To: "U.S. Metric Association" <usma@...>
Sent: Sunday, January 07, 2001 6:07 PM
Subject: [USMA:10337] To BE Inc.


> This message went to BE Inc. and I wonder what, if ever, they will answer.
I will de-install BEos because of what can be read below and also  because
it does not support my graphics card,

Han

<snip>

This is what happened to day when I was using an Internet  computer at the
university. When I just sat down it was just re-starting. Then I saw the
wrong time and date settings. Some $@#$&*# idiot
had just changed the country settings to USA. So, I immediately re-set it to
the original Dutch settings. There are Americans and British here and I
think
that one of them wanted to introduce us to a very 'advanced and
state-of-the-art' time and date format. Now whenever I see a computer here
with the wrong
settings, I will restore the correct ones at once,

Han

On 2001-Jan-19 Han Maenan wrote:


> Although I have set my Windows 98 computer to the
> ISO 8601 standard, I still have the format
> mm-dd-yyyy AM/PM  lurking somewhere in my computer
> and it always pops up in my e-mail headers.
> Just look at the header below. Does anybody know
> how to get rid of this?

> ----- Original Message -----
> From: "Han Maenen" <han.maenen@...>
> To: "U.S. Metric Association" <usma@...>
> Sent: Sunday, January 07, 2001 6:07 PM
> Subject: [USMA:10337] To BE Inc.



[2001-Jan-20]


The date format that email uses is defined in an Internet Standard known as
an RFC. There are several RFC documents relevant to email. I do not have the
RFC numbers to hand, but they can be easily found, by reference to the
Internic Web Site, or by using any common Search Engine on the Web. One is
possibly RFC 822, but there are several later ones as well.

There are several date formats defined for email usage, and the one seen
above is probably the most common. These ad-hoc standards were put in place
long before anyone had any real interest in the Year 2000, or in ISO 8601.
The original date format only allowed a two-digit year. With the Year 2000
impending, the specification was updated several years ago, and defined in a
newer RFC numbered document. This modification catered for a four-digit
year. Rather than have a major revision of the way email works, and start
using ISO 8601, they simply decided to stick with the old order, and just
change the year to four-digits. Email systems have to parse that date in
order to get any sense out of it (as several different date forms are
allowed - but none of them are Year-Month-Day based); whereas if ISO 8601
had been used, the date could have just been used 'as is'.

This is why, when I write articles about the usage of ISO 8601 on the
Internet I always say that...

"Technologies like XML only allow the Year-Month-Day date format. It is also
a core standard of the Internet now that both Internic and the World Wide
Web Consortium (W3C) recommend its use for all *NEW* Internet or electronic
protocols"

So we have to live with the legacy formats in some systems for the time
being. However there are enough people aware of ISO 8601, that should the
email system need a further major revision, then there would be many people
suggesting and requesting a change to the Year-Month-Day date format. It
will happen, just not yet in this case. At the present we need to focus on
new technologies and ensure that these use it from the very beginning.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2001-01-20]

.end

I am looking at how the standard specifies durations and recurring
time intervals. Do any of you have experience with this?

There does not seem to be a spec for how to do the arithmetic.
If I have a start date plus a duration of 1 month, what does this
mean?
Do I add 30 days? Do I add 1 to the month of the start date?
I will get different answers depending on the rules used.
I may also get different answers depending on the order in which
I add the elements (year before month or vice versa).

If my start date is Mar. 31, and I add 1 month, since April 31 is not
valid, do I move to May 1, or April 30. I can see arguments either
way. For example, I might expect adding one month to put me somewhere
in April. Alternatively, it would be nice to have subtraction of the
end date from the start date return the original duration and not a
new value.

Also, the standard is unclear about the of the number sign on
recurrences. When is it needed, or is it redundant?

Is there any specification for this or does it all need to be handled
by mutual agreements.
tex

$ There does not seem to be a spec for how to do the arithmetic.
$ If I have a start date plus a duration of 1 month, what does this
$ mean?
$ Do I add 30 days? Do I add 1 to the month of the start date?
$ I will get different answers depending on the rules used.
$ I may also get different answers depending on the order in which
$ I add the elements (year before month or vice versa).
$
$ If my start date is Mar. 31, and I add 1 month, since April 31 is not
$ valid, do I move to May 1, or April 30. I can see arguments either
$ way. For example, I might expect adding one month to put me somewhere
$ in April. Alternatively, it would be nice to have subtraction of the
$ end date from the start date return the original duration and not a
$ new value.

   Let's say your start date is 2001-01-22 (January 22, 2001).
When is your anniversary date?  How do you calculate it?
Do you add 365 days?  Do you add 1 to the year of the start date?
If you add 1 to the year, does it mean you're adding 365 or 366 days?
It depends how many days there are in that year, right?  So, wouldn't
it be logical to follow the same rule?  That is, if your start date
is March 31, then "one month from March 31" would be April 30, right?

$ Also, the standard is unclear about the of the number sign on
$ recurrences. When is it needed, or is it redundant?

   Hmm?

$ Is there any specification for this or does it all need to be handled
$ by mutual agreements.

   Hmm?


--
Archie Medrano   amedrano@...   http://euclid.ucsd.edu/~amedrano/
Happy New Year 2001 * Happy New (3rd) Millennium (Jan 1, 2001 - Dec 31, 3000)
"The most exciting phrase in science, the one that heralds
  new discoveries, is not 'Eureka' (I found it!) but
  'That's funny...'" -- Isaac Asimov

Archie Medrano wrote:
>   Let's say your start date is 2001-01-22 (January 22, 2001).
> When is your anniversary date?  How do you calculate it?
> Do you add 365 days?  Do you add 1 to the year of the start date?
> If you add 1 to the year, does it mean you're adding 365 or 366 days?
> It depends how many days there are in that year, right?  So, wouldn't
> it be logical to follow the same rule?  That is, if your start date
> is March 31, then "one month from March 31" would be April 30, right?

OK, but 1 month from March 30 is April 30.
Seems odd that you can add one month to either date and get April 30.

On the othe hand, there is no way to add one month and get to
March 30 or 31, since Feb. only gets to 29 at most.


> $ Also, the standard is unclear about the of the number sign on
> $ recurrences. When is it needed, or is it redundant?
>
>   Hmm?

The standard says you put # on recurring intervals, for ex.
you can write R5P1M#5 to indicate 5 recurrences of 1 month.
But you can also write R5P1M. So what is the purpose of the #5?

>
> $ Is there any specification for this or does it all need to be handled
> $ by mutual agreements.
>
>   Hmm?

I can imagine a lot of rules for date arithmetic. The anniversary
calculations you allude to, are one way to do it, but not the only
way. Presuming 1M is a fixed duration of 30days is another way.
Applications can agree to use either approach. I am interested if
somewhere an approach is written up that a majority of applications
(or perhaps c or java libraries) follow, to do a better job of insuring
interoperability when exchanging date information.

thanks for replying!

>
> --
> Archie Medrano   amedrano@...   http://euclid.ucsd.edu/~amedrano/
> Happy New Year 2001 * Happy New (3rd) Millennium (Jan 1, 2001 - Dec 31, 3000)
> "The most exciting phrase in science, the one that heralds
>  new discoveries, is not 'Eureka' (I found it!) but
>  'That's funny...'" -- Isaac Asimov
>
> ISO8601 Community email addresses:
>   Post message: ISO8601@onelist.com
>   Subscribe:    ISO8601-subscribe@onelist.com
>   Unsubscribe:  ISO8601-unsubscribe@onelist.com
>   List owner:   ISO8601-owner@onelist.com
>   URL : http://www.onelist.com/community/ISO8601

--
According to Murphy, nothing goes according to Hoyle.
--------------------------------------------------------------------------
Tex Texin                      Director, International Business
mailto:Texin@...      +1-781-280-4271 Fax:+1-781-280-4655
Progress Software Corp.        14 Oak Park, Bedford, MA 01730

http://www.Progress.com        #1 Embedded Database

Globalization Program
http://www.Progress.com/partners/globalization.htm
---------------------------------------------------------------------------

Tex Texin writes:
  > The standard says you put # on recurring intervals, for ex.
  > you can write R5P1M#5 to indicate 5 recurrences of 1 month.
  > But you can also write R5P1M. So what is the purpose of the #5?

It looks redundant to me, indeed perhaps it should not be in the
standard.  Are you looking at the published standard ISO 8601:2000?
I have not yet seen the document myself.
--
Pete Forman                 -./\.- Disclaimer: This post is originated
WesternGeco                   -./\.-  by myself and does not represent
pete.forman@...     -./\.-  opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef  -./\.-  Hughes or their divisions.

Is anyone aware of standards on costweeks?

My understanding was that they were an international standard, my
enquiries to date suggest that they are internal to a company.
My company use them for accounting and manufacturing processing,
that are subsequently broken into cost periods.
Ie. costweek 02/2001 is Sat 2001-01-06 to Fri 2001-01-12

Dave Clark
mailto:dave.clark@...

I am looking at the FDIS version of 8601:2000.
Tex

Pete Forman wrote:
>
> Tex Texin writes:
>  > The standard says you put # on recurring intervals, for ex.
>  > you can write R5P1M#5 to indicate 5 recurrences of 1 month.
>  > But you can also write R5P1M. So what is the purpose of the #5?
>
> It looks redundant to me, indeed perhaps it should not be in the
> standard.  Are you looking at the published standard ISO 8601:2000?
> I have not yet seen the document myself.
> --
> Pete Forman                 -./\.- Disclaimer: This post is originated
> WesternGeco                   -./\.-  by myself and does not represent
> pete.forman@...     -./\.-  opinion of Schlumberger, Baker
> http://www.crosswinds.net/~petef  -./\.-  Hughes or their divisions.
>
> ISO8601 Community email addresses:
>   Post message: ISO8601@onelist.com
>   Subscribe:    ISO8601-subscribe@onelist.com
>   Unsubscribe:  ISO8601-unsubscribe@onelist.com
>   List owner:   ISO8601-owner@onelist.com
>   URL : http://www.onelist.com/community/ISO8601

--
According to Murphy, nothing goes according to Hoyle.
--------------------------------------------------------------------------
Tex Texin                      Director, International Business
mailto:Texin@...      +1-781-280-4271 Fax:+1-781-280-4655
Progress Software Corp.        14 Oak Park, Bedford, MA 01730

http://www.Progress.com        #1 Embedded Database

Globalization Program
http://www.Progress.com/partners/globalization.htm
---------------------------------------------------------------------------

I cannot believe I am the first to notice this, but....

The date listing on the eGroups ISO8601 is in format mm/dd/yyyy.
Who can we get to fix this?

Dave Clark

[2001-Jan-24]


Hi All,
    Probably the longest message thread we have had in ages!



On  2001-Jan-22  Tex Texin  <texin@...>  wrote:


> I am looking at how the standard specifies durations and recurring
> time intervals. Do any of you have experience with this?

The ISO 8601 standard specifies a moment or a point in time, with whatever
precision you want: Year-Month-Day-Hour-Minute-Second-Fraction... knock off
elements from the right hand side to achieve the level of accuracy you require.

It also specifies a period or duration of time in one of several ways:
These can be defined with both a Start and a Stop, Date and/or Time. The
other way is by either a Start or a Stop, Date and/or Time, combined with a
Period or Duration of time, with units up to many years, or down as fas as
only a fraction of a second.

There is nothing in there (ISO 8601:1988) about repetitive events.
Repetitive events are usually just listed by their dates. However, either
the  Year-DayOfYear (Ordinal Date, eg 1999-365) format  or the
Year-WeekOfYear-DayOfWeek  format  (eg 1999-W24-D5) is good for calculating
repetitive events as it gets away from the idea of months, and divides the
year only by individually numbered days, or by just week numbers within the
year, and then by days of the week. The latter is designed for factory
production schedules. The former has been used by astronomers for a very
long time, as it is easy to keep adding say, 4.716 days to a simple numbered
day-in-the-year scheme than it is to do this with other date formats. The
Gregorian Calendar otherwise gets in the way, and is not at all logical.


> There does not seem to be a spec for how to do the arithmetic.

Correct. The standard is not meant for this.


> If I have a start date plus a duration of 1 month, what does this
> mean?
> Do I add 30 days? Do I add 1 to the month of the start date?
> I will get different answers depending on the rules used.
> I may also get different answers depending on the order in which
> I add the elements (year before month or vice versa).

It's all very confusing. The publication that you require is, I think, the
IBM guide to the Year 2000. The publication number is GC28-1251-xx, where xx
is the issue number. This was widely available as Text, HTML, and PDF on
various IBM Sites over the last few years. The Title was 'The Year 2000 and
2-digit Dates: A Guide for Planning and Implementation'. Catchy, eh? I
believe there was discussion there about this (but I may be wrong).


> If my start date is Mar. 31, and I add 1 month, since April 31 is not
> valid, do I move to May 1, or April 30. I can see arguments either
> way. For example, I might expect adding one month to put me somewhere
> in April. Alternatively, it would be nice to have subtraction of the
> end date from the start date return the original duration and not a
> new value.

The Gregorian Calendar is the reason for this mess. If you forget about
'months' and divide the year into 13 periods of 4 weeks you will reduce the
problems. I once worked for a company that paid wages out exactly every 4
weeks. If you are doing something repetitive for a business the biggest
problem is when the time falls over the weekend, or at 03:00 hours. You
gonna pay overtime for that? Using a Week-based rather then 'month'-based
format could avoid the problem (but you'll still get hit by Bank Holidays).


> Also, the standard is unclear about the of the number sign on
> recurrences. When is it needed, or is it redundant?

> Is there any specification for this or does it all need to be handled
> by mutual agreements.

There is discussion in a number of books, and on a number of Web Sites, but
there are too many variables as to what you may wish to do. If you want
something to happen on the third Thursday of the month, or the closest
Thursday to the 22nd of the month, or every 4 weeks, or every 23 days then
that is what you have to design and code... and some of the algorithms will
be eye-watering. As for having an unambiguous way of writing any, or all, of
these, then I think that is a long way off. Dates like 1999-12-31 or
2001-025 or 2001-W04-D5 are reasonably clear, but the strings to represent
the closest Thursay to the 22nd of the month, etc are too complicated.
Wisely the ISO 8601 boys stayed clear of this.




On  2001-Jan-23  Archie Medrano  <amedrano@...>  wrote:


>   Let's say your start date is 2001-01-22 (January 22, 2001).
> When is your anniversary date?  How do you calculate it?
> Do you add 365 days?  Do you add 1 to the year of the start date?
> If you add 1 to the year, does it mean you're adding 365 or 366 days?
> It depends how many days there are in that year, right?  So, wouldn't
> it be logical to follow the same rule?  That is, if your start date
> is March 31, then "one month from March 31" would be April 30, right?

There are so many possibilities, that agreement would be very hard, and
still open to confusion.




On 2001-Jan-23  Tex Texin  <texin@...>  wrote:


> OK, but 1 month from March 30 is April 30.
> Seems odd that you can add one month to either date and get April 30.

Crazy. That IBM book I mentioned, I remember that it said that some moves
were one way, you could not get back to your start date, only the day before
of after.


> On the other hand, there is no way to add one month and get to
> March 30 or 31, since Feb. only gets to 29 at most.

It's the concept of the 'month' that screws it up. Forget it, and move to a
method counting weeks within the year; if you wanna keep your hair, your
sanity, or both.


> I can imagine a lot of rules for date arithmetic. The anniversary
> calculations you allude to, are one way to do it, but not the only
> way. Presuming 1M is a fixed duration of 30days is another way.
> Applications can agree to use either approach. I am interested if
> somewhere an approach is written up that a majority of applications
> (or perhaps c or java libraries) follow, to do a better job of ensuring
> interoperability when exchanging date information.

I don't know if this will help, as I haven't looked at his Web Site for some
time, but <http://www.merlyn.demon.co.uk/> had some C date and time stuff on
it, and links to others. John Stockton was always helpful when I emailed him
back a year or so ago.




On  2001-Jan-23  Pete Forman  <pete.forman@...>  wrote:


> > The standard says you put # on recurring intervals, for ex.
> > you can write R5P1M#5 to indicate 5 recurrences of 1 month.
> > But you can also write R5P1M. So what is the purpose of the #5?

> It looks redundant to me, indeed perhaps it should not be in the
> standard.  Are you looking at the published standard ISO 8601:2000?
> I have not yet seen the document myself.

I haven't seen this business with the # before.

I haven't seen any later edition of ISO 8601 than the 1988 version (except a
marked up draft several years ago).




On 2001-Jan-23  Tex Texin  <texin@...>  wrote:


> I am looking at the FDIS version of 8601:2000.

Please explain what FDIS is. Additionally, is this document published on the
Net anywhere publicly accessible.



I'm looking forward to the rest of the comments on this thread.
If I have any further thoughts, I'll bung them in, later in the week.




Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2001-01-24]

.end

On  2001-Jan-23  Dave Clark  <dave.clark@...>  wrote:


> I cannot believe I am the first to notice this, but....
>
> The date listing on the eGroups ISO8601 is in format mm/dd/yyyy.
> Who can we get to fix this?



[2001-Jan-24]


Er, you're not, but no-one at egroups takes any notice of emails. Several in
this group have already tried.

You'll laugh at this. At the beginning of last year all messages were
stamped with the date having the year 100. Well, I suppose that it is one
more than 99!!

It took a few days before 2000 started appearing. Maybe soon we can convince
them to use Year-Month-Day.

IBM have already done it. FTP Search at <http://ftpsearch.lycos.com/> has
done it (well the software was written in Norway where Y-M-D is well known),
as have several other search engines. Parts of NASA, at
<http://umbra.nascom.nasa.gov/> and <http://sohowww.nascom.nasa.gov/> have
joined in. As more sites changeover, the easier it becomes to find examples
when suggesting that others make the change. However with thousands of new
sites coming online each day, we can never keep up. That is why the next
thrust is in ensuring that automated systems, like those run on XML all use
ISO 8601 as the default, and preferably the ONLY, allowed date format.

I belong to an astronomy group that also has an egroups account. We always
find it funny that egroups doesn't use the format that astronomers have been
comfortable with for the last 200 years or more.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2001-01-24]

.end

On  2001-Jan-23  Dave Clark  <dave.clark@...>  wrote:


> Is anyone aware of standards on costweeks?
>
> My understanding was that they were an international standard, my
> enquiries to date suggest that they are internal to a company.
> My company use them for accounting and manufacturing processing,
> that are subsequently broken into cost periods.
> Ie. costweek 02/2001 is Sat 2001-01-06 to Fri 2001-01-12




[2001-Jan-24]


Yes, ISO 8601 covers this. There are THREE main date formats defined in
International Standard ISO 8601:

Calendar Date:
                      Year-MonthofYear-DayOfMonth    1999-12-31

Ordinal Day of Year (Ordinal Date):
                      Year-DayOfYear                 1999-365

Year, Week Number in Year, and Day Number in Week:
                      Year-WeekofYear-DayOfWeek      1999-W48-D4


The standard defines optional hyphens as separators.

The Year may be two or four digits long, but post-2000 everyone should
ALWAYS use all four digits just to completely eradicate any doubt as to the
'Century'. Additionally now that the two-digit year, the month, and the day
all have values of 12 or less for the first 12 days of each month, it is
imperative to use a four-digit year, just so that you can find it in the
date. Dates like '04/07/03' have too many ambiguities to contemplate.

The forms may be truncated from the left, such that --12-31 (or -1231) is
simply December 31st of an unspecified year, or of the current year
(depending on what you have agreed with your data interchange partner).

The forms may alternatively have some elements removed from the right, such
that '1999-12' simply means 1999-December, and '1999' is just the year 1999.

You need to read the web sites at both
<http://www.cl.cam.ac.uk/~mgk25/iso-time.html>  and
<http://www.jat.org/jtt/datetime.html>  to get up to speed on these topics
in just an hour or so.

The info at Cambridge University (cl.cam.ac.uk) also explains how the days
are numbered within the week. It also helps you to decide what the week
number is within the year, and how you decide where the week numbering
transitions at a year boundary.

Some companies follow the ISO 8601 standard for week numbering, but other
organisations do not. There are many self-invented schemes. Some start the
week on Sunday rather than on Monday. Some number the days from 1 to 7,
others number them from 0 to 6. The whole thing is a mess, but the ISO
standards are the 'top-layer', and are what we should be doing.

Beware of JavaScript which numbers the months of the year from 0 to 11. Who
the hell decided on that idea?


The ISO 8601 standard is held (in paper form) at some main public reference
libraries in the UK. Here in Poole we have a copy. You need to ask for
British Standard BS EN 28601:1988 or any later revision that has been
published. You may find an older obsolete version numbered as BS 7151 in
some places (but the wording is exactly the same - the number only changed
because we adopted the Euro EN-numbered version in 1988; both are exactly
the same as ISO 8601).

Siemens is also here in Poole (I know a few people who worked there - One of
those people subscribes to this list) had a very good technical library. I
would hope that the company already has a copy of the standard archived
somewhere. However I would still recommend getting the free, online, PDF
version. It's one of a very few ISO satndards available on the Internet,
simply because of it's vital role in solving the 'Year 2000 Problem' with
computer systems last year.


The CostWeek form that you are looking for is the Year-WeekOfYear-DayOfWeek
format. This is defined in the ISO 8601 standard, which has been adopted
virtually world-wide now. For a list of the equivalent official standards
numbers used in many different countries see:
<http://www.qsl.net/g1smd/isoimp.htm>.


A search using any competent Internet Search Engine, when fed with 'ISO8601'
or 'ISO 8601' (both with and without spaces - it does make a difference),
will find hundreds of useful sites that discuss this topic.


Get a copy of the official ISO standard, in PDF format, from either
<http://www.qsl.net/g1smd/>  and follow the link to the 'FTP Site'; or
alternatively try  <http://www.iso.ch/markete/8601.pdf>.  The QSL Net site
has both the official published 1988 standard, and a marked-up draft copy of
the 1998 version, which is still waiting to be published as the updated 2000
version.


The ISO 8601 standard also has several other sections:

This first is about time. This is stated in  Hours:Minutes:Seconds  order
and always in the 24-hour format. Again, the colon separators are optional
and the various forms can be truncated from the left (but NOT when combined
with a date), or can be made reduced-precision by removing elements from the
right.

The standard contains the modern 'Gregorian Calendar' rules for calculating
Leap Years, and a whole section about periods or lengths of time.

The standard (1988 version) has nothing much to say about repetitive events.
It is about specifying only a point in time, or a duration at a fixed point
in time, not about multiple events that happen at different times.


These Web Sites may also serve as starting points for more information:
<http://www.cl.cam.ac.uk/~mgk25/iso-time.html>
<http://www.cv.nrao.edu/y2k/>
<http://www.saqqara.demon.co.uk/datefmt.htm>
<http://www.qsl.net/g1smd/isoimp.htm>
<http://www.merlyn.demon.co.uk/>
<http://www.metric1.org/dateandtime.htm>
<http://www.hut.fi/~jkorpela/iso8601.html>
<http://www.ucs.co.za/uc/webtest/y2000.htm>
along with the many links out of these sites to other related sites.



I see that Dave Clark works for Siemems. I want to ask why my Siemens C35i
mobile phone allows 12.31.1999 and 31.12.1999 date format, but does not
allow the 1999.12.31 date format? Perhaps Dave could give me some email
addresses of people in the relevant mobile phone division that I could write
to directly. The Siemens Web Site, software, and products, have been berated
in this email discussion group a few months ago for this; but no-one here
has any direct contacts...




Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2001-01-24]

.end

Dave Clark <dave.clark@...> asked:

> Is anyone aware of standards on costweeks?
>
> My understanding was that they were an international standard, my
> enquiries to date suggest that they are internal to a company.
> My company use them for accounting and manufacturing processing,
> that are subsequently broken into cost periods.
> I.e. costweek 02/2001 is Sat 2001-01-06 to Fri 2001-01-12

I am very sure this is one of those 'platform dependent' things.  I have
recently worked for one company whose accounting weeks ran from Monday
through Sunday, and now another whose weeks run Saturday through Friday as
yours does.

The same is true of fiscal years. Some companies have fiscal years that
coincide with calendar years, but others' years start and end in the middle
of  a calendar year (but generally on quarter boundaries I think). As a
contract employee of a U.S. government agency I am particularly aware that
the U.S.  federal government's fiscal year begins on <CCYY>-10-01 and ends
on <CCYY+1>-09-30.

--
Bob Hirsch   Bob@...
The preceding has been an opinion by a concerned citizen.

Ian,

Thanks for the lengthy reply.

I am basing my comments on 8601:2000 which does have recurring
events.

I will look for the IBM book.
However, I am concerned that applications referring to 8601 as
a standard for interchange, need to have a definition for the
arithmetic in the intervals being represented. If one of uses the IBM
book,
and another developer uses a different approach, we don't
really have a standard for interchange...

Yes, there are many eye-watering ways to specify dates in terms of
other dates. However, unless the standard says uses the "week"-approach
(no pun with "weak" intended :-) ) then I can't insist on this to the
applications I might want to integrate with...

What I need is a specification that interprets the date arithmetic
that is implied in 8601:2000, or I may as well be using sand in
an hourglass for my date and time calculations...

I am pretty sure I am tilting at windmills now, and there is no
such spec...
tex

g1smd@... wrote:
>
> [2001-Jan-24]
>
> Hi All,
>    Probably the longest message thread we have had in ages!
>
> On  2001-Jan-22  Tex Texin  <texin@...>  wrote:
>
> > I am looking at how the standard specifies durations and recurring
> > time intervals. Do any of you have experience with this?
>
> The ISO 8601 standard specifies a moment or a point in time, with whatever
> precision you want: Year-Month-Day-Hour-Minute-Second-Fraction... knock off
> elements from the right hand side to achieve the level of accuracy you
require.
>
> It also specifies a period or duration of time in one of several ways:
> These can be defined with both a Start and a Stop, Date and/or Time. The
> other way is by either a Start or a Stop, Date and/or Time, combined with a
> Period or Duration of time, with units up to many years, or down as fas as
> only a fraction of a second.
>
> There is nothing in there (ISO 8601:1988) about repetitive events.
> Repetitive events are usually just listed by their dates. However, either
> the  Year-DayOfYear (Ordinal Date, eg 1999-365) format  or the
> Year-WeekOfYear-DayOfWeek  format  (eg 1999-W24-D5) is good for calculating
> repetitive events as it gets away from the idea of months, and divides the
> year only by individually numbered days, or by just week numbers within the
> year, and then by days of the week. The latter is designed for factory
> production schedules. The former has been used by astronomers for a very
> long time, as it is easy to keep adding say, 4.716 days to a simple numbered
> day-in-the-year scheme than it is to do this with other date formats. The
> Gregorian Calendar otherwise gets in the way, and is not at all logical.
>
> > There does not seem to be a spec for how to do the arithmetic.
>
> Correct. The standard is not meant for this.
>
> > If I have a start date plus a duration of 1 month, what does this
> > mean?
> > Do I add 30 days? Do I add 1 to the month of the start date?
> > I will get different answers depending on the rules used.
> > I may also get different answers depending on the order in which
> > I add the elements (year before month or vice versa).
>
> It's all very confusing. The publication that you require is, I think, the
> IBM guide to the Year 2000. The publication number is GC28-1251-xx, where xx
> is the issue number. This was widely available as Text, HTML, and PDF on
> various IBM Sites over the last few years. The Title was 'The Year 2000 and
> 2-digit Dates: A Guide for Planning and Implementation'. Catchy, eh? I
> believe there was discussion there about this (but I may be wrong).
>
> > If my start date is Mar. 31, and I add 1 month, since April 31 is not
> > valid, do I move to May 1, or April 30. I can see arguments either
> > way. For example, I might expect adding one month to put me somewhere
> > in April. Alternatively, it would be nice to have subtraction of the
> > end date from the start date return the original duration and not a
> > new value.
>
> The Gregorian Calendar is the reason for this mess. If you forget about
> 'months' and divide the year into 13 periods of 4 weeks you will reduce the
> problems. I once worked for a company that paid wages out exactly every 4
> weeks. If you are doing something repetitive for a business the biggest
> problem is when the time falls over the weekend, or at 03:00 hours. You
> gonna pay overtime for that? Using a Week-based rather then 'month'-based
> format could avoid the problem (but you'll still get hit by Bank Holidays).
>
> > Also, the standard is unclear about the of the number sign on
> > recurrences. When is it needed, or is it redundant?
>
> > Is there any specification for this or does it all need to be handled
> > by mutual agreements.
>
> There is discussion in a number of books, and on a number of Web Sites, but
> there are too many variables as to what you may wish to do. If you want
> something to happen on the third Thursday of the month, or the closest
> Thursday to the 22nd of the month, or every 4 weeks, or every 23 days then
> that is what you have to design and code... and some of the algorithms will
> be eye-watering. As for having an unambiguous way of writing any, or all, of
> these, then I think that is a long way off. Dates like 1999-12-31 or
> 2001-025 or 2001-W04-D5 are reasonably clear, but the strings to represent
> the closest Thursay to the 22nd of the month, etc are too complicated.
> Wisely the ISO 8601 boys stayed clear of this.
>
> On  2001-Jan-23  Archie Medrano  <amedrano@...>  wrote:
>
> >   Let's say your start date is 2001-01-22 (January 22, 2001).
> > When is your anniversary date?  How do you calculate it?
> > Do you add 365 days?  Do you add 1 to the year of the start date?
> > If you add 1 to the year, does it mean you're adding 365 or 366 days?
> > It depends how many days there are in that year, right?  So, wouldn't
> > it be logical to follow the same rule?  That is, if your start date
> > is March 31, then "one month from March 31" would be April 30, right?
>
> There are so many possibilities, that agreement would be very hard, and
> still open to confusion.
>
> On 2001-Jan-23  Tex Texin  <texin@...>  wrote:
>
> > OK, but 1 month from March 30 is April 30.
> > Seems odd that you can add one month to either date and get April 30.
>
> Crazy. That IBM book I mentioned, I remember that it said that some moves
> were one way, you could not get back to your start date, only the day before
> of after.
>
> > On the other hand, there is no way to add one month and get to
> > March 30 or 31, since Feb. only gets to 29 at most.
>
> It's the concept of the 'month' that screws it up. Forget it, and move to a
> method counting weeks within the year; if you wanna keep your hair, your
> sanity, or both.
>
> > I can imagine a lot of rules for date arithmetic. The anniversary
> > calculations you allude to, are one way to do it, but not the only
> > way. Presuming 1M is a fixed duration of 30days is another way.
> > Applications can agree to use either approach. I am interested if
> > somewhere an approach is written up that a majority of applications
> > (or perhaps c or java libraries) follow, to do a better job of ensuring
> > interoperability when exchanging date information.
>
> I don't know if this will help, as I haven't looked at his Web Site for some
> time, but <http://www.merlyn.demon.co.uk/> had some C date and time stuff on
> it, and links to others. John Stockton was always helpful when I emailed him
> back a year or so ago.
>
> On  2001-Jan-23  Pete Forman  <pete.forman@...>  wrote:
>
> > > The standard says you put # on recurring intervals, for ex.
> > > you can write R5P1M#5 to indicate 5 recurrences of 1 month.
> > > But you can also write R5P1M. So what is the purpose of the #5?
>
> > It looks redundant to me, indeed perhaps it should not be in the
> > standard.  Are you looking at the published standard ISO 8601:2000?
> > I have not yet seen the document myself.
>
> I haven't seen this business with the # before.
>
> I haven't seen any later edition of ISO 8601 than the 1988 version (except a
> marked up draft several years ago).
>
> On 2001-Jan-23  Tex Texin  <texin@...>  wrote:
>
> > I am looking at the FDIS version of 8601:2000.
>
> Please explain what FDIS is. Additionally, is this document published on the
> Net anywhere publicly accessible.
>
> I'm looking forward to the rest of the comments on this thread.
> If I have any further thoughts, I'll bung them in, later in the week.
>
> Cheers,
>
> Ian.
>
> <mail://g1smd@amsat.org>
>
> <http://www.qsl.net/g1smd/>
> <http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
>
> <ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
> <ftp://ftp.qsl.net/pub/g1smd/>
>
> [2001-01-24]
>
> .end
>
> ISO8601 Community email addresses:
>   Post message: ISO8601@onelist.com
>   Subscribe:    ISO8601-subscribe@onelist.com
>   Unsubscribe:  ISO8601-unsubscribe@onelist.com
>   List owner:   ISO8601-owner@onelist.com
>   URL : http://www.onelist.com/community/ISO8601

--
According to Murphy, nothing goes according to Hoyle.
--------------------------------------------------------------------------
Tex Texin                      Director, International Business
mailto:Texin@...      +1-781-280-4271 Fax:+1-781-280-4655
Progress Software Corp.        14 Oak Park, Bedford, MA 01730

http://www.Progress.com        #1 Embedded Database

Globalization Program
http://www.Progress.com/partners/globalization.htm
---------------------------------------------------------------------------

I contacted them about this months ago, to no avail. They did not bother to
answer, well this IS an answer as far as I am concerned: E-groups
(Onelist.com)wants the death of ISO 8601.
This company has European websites in languages like French, German and
Italian, but what about the settings? Do they respect the international ones
there? NO! The settings are mm-dd-yyyy AM/PM on these sites, targeted at
people who do NOT use them!
My conclusion is: E-groups (Onelist.com) is just as bad as Be.Inc.; both
companies want to destroy ISO 8601 and to impose this medieval garbage on
the world. Maybe we should look for another provider of this kind.

If I could, I would have no truck with this company at all,

Han

----- Original Message -----
From: "Dave Clark" <dave.clark@...>
To: <ISO8601@egroups.com>
Sent: Tuesday, 2001 January 23, 11:43
Subject: [ISO8601] egroups date listing


> I cannot believe I am the first to notice this, but....
>
> The date listing on the eGroups ISO8601 is in format mm/dd/yyyy. Who can
we get to fix this?

  Dave Clark

Seems a bit strong to consider the ignorance of companies that
do not use 8601, as hostile and wanting to destroy 8601.
They are just being ignorant. Am I missing something?
tex

Han Maenen wrote:
>
> I contacted them about this months ago, to no avail. They did not bother to
> answer, well this IS an answer as far as I am concerned: E-groups
> (Onelist.com)wants the death of ISO 8601.
> This company has European websites in languages like French, German and
> Italian, but what about the settings? Do they respect the international ones
> there? NO! The settings are mm-dd-yyyy AM/PM on these sites, targeted at
> people who do NOT use them!
> My conclusion is: E-groups (Onelist.com) is just as bad as Be.Inc.; both
> companies want to destroy ISO 8601 and to impose this medieval garbage on
> the world. Maybe we should look for another provider of this kind.
>
> If I could, I would have no truck with this company at all,
>
> Han
>
> ----- Original Message -----
> From: "Dave Clark" <dave.clark@...>
> To: <ISO8601@egroups.com>
> Sent: Tuesday, 2001 January 23, 11:43
> Subject: [ISO8601] egroups date listing
>
> > I cannot believe I am the first to notice this, but....
> >
> > The date listing on the eGroups ISO8601 is in format mm/dd/yyyy. Who can
> we get to fix this?
>
>  Dave Clark
>
> ISO8601 Community email addresses:
>   Post message: ISO8601@onelist.com
>   Subscribe:    ISO8601-subscribe@onelist.com
>   Unsubscribe:  ISO8601-unsubscribe@onelist.com
>   List owner:   ISO8601-owner@onelist.com
>   URL : http://www.onelist.com/community/ISO8601

--
According to Murphy, nothing goes according to Hoyle.
--------------------------------------------------------------------------
Tex Texin                      Director, International Business
mailto:Texin@...      +1-781-280-4271 Fax:+1-781-280-4655
Progress Software Corp.        14 Oak Park, Bedford, MA 01730

http://www.Progress.com        #1 Embedded Database

Globalization Program
http://www.Progress.com/partners/globalization.htm
---------------------------------------------------------------------------

g1smd@... writes:
  > On  2001-Jan-23  Dave Clark  <dave.clark@...>  wrote:
  > > Is anyone aware of standards on costweeks?
  > >
  > > My understanding was that they were an international standard, my
  > > enquiries to date suggest that they are internal to a company.
  > > My company use them for accounting and manufacturing processing,
  > > that are subsequently broken into cost periods.
  > > Ie. costweek 02/2001 is Sat 2001-01-06 to Fri 2001-01-12
  >
  > Yes, ISO 8601 covers this.

Strictly speaking it does not.  Weeks run from Mon to Sun only.  (I
realize that you spelt out the details later in your post.)  Even if
it does not matter to Dave if the weekend is counted in the wrong
week, the ordinal number of the week may differ.


  > Beware of JavaScript which numbers the months of the year from 0 to
  > 11. Who the hell decided on that idea?

The same people who stored the year as tm_year = years since 1900 ;-)

struct tm has been defined that way in Unix for many years now.  It
was certainly well established in 1989.


  > ... which is still waiting to be published as the updated 2000
  > version.

ISO 8601:2000 was published on 2000-12-21.  It may be purchased from
<http://www.iso.ch> and no doubt the other places in due course.
--
Pete Forman                 -./\.- Disclaimer: This post is originated
WesternGeco                   -./\.-  by myself and does not represent
pete.forman@...     -./\.-  opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef  -./\.-  Hughes or their divisions.

> Seems a bit strong to consider the ignorance of companies that
> do not use 8601, as hostile and wanting to destroy 8601.

Absolutely:

"Never attribute to malice that which is adequately explained by
stupidity..."

I am sorry, but I disagree. They are not ignorant. What makes me believe
that what they are doing is intentional is that E-groups has sites in Europe
in French, German and Italian with mm-dd-yyyy AM/PM settings. They work
abroad and they do not know that these settings are not used there? At least
they could have used the now obsolete European settings of dd-mm-yyyy 24
hour on these sites. That would have convinced me of their good will.

The other company, Be.Inc. has offices and probably production facilities in
France. Nobody can make me believe that they are ignorant. Apple and
Microsoft know about local settings and ISO 8601, Amiga knew about them too
and I have to believe that Be.Inc. doesn't?
No way, I remain where I stand and that is that companies that work abroad,
like Be.Inc and Onelist.com, know about ISO 8601. If, however, they insist
on bombarding European and other non-English speaking peoples with the US
formats and even more, FORCING them to use these formats on pain of error
messages and even system crashes, then I am convinced that they are trying
to do away with ISO 8601 by fooling their international clients into
accepting the settings used in the USA as the real global standard.

Another indication is that if anybody contacts them on this issue they do
not bother to answer.

I remember from a class at university years ago, in the era of 286 computers
and DOS, when the lecturer  HAD to instruct us to type in the US date and
time when starting the computer, or the computer would stop in its tracks
with an error message. Then something had to be written down on paper or on
a word processor and a student asked if the date had to be written the same
way as he had done when switching on the computer. No, said the lecturer,
you can do it in the format you are accustomed to. I am grateful that the
lecturer limited the damage, but this event also showed me the subtle ways
in which people can be made to adopt something.

The only companies which can be excused because of ignorance are those that
work entirely within the USA and these were not my target.

Han

----- Original Message -----
From: "Tex Texin" <texin@...>
To: <ISO8601@egroups.com>
Sent: Wednesday, 2001 January 24, 08:44
Subject: Re: [ISO8601] egroups date listing


> Seems a bit strong to consider the ignorance of companies that do not use
8601, as hostile and wanting to destroy 8601.
They are just being ignorant. Am I missing something?
  tex

  Han Maenen wrote:

  I contacted them about this months ago, to no avail. They did not bother to
answer, well this IS an answer as far as I am concerned: E-groups
(Onelist.com)wants the death of ISO 8601.
This company has European websites in languages like French, German and
Italian, but what about the settings? Do they respect the international ones
there? NO! The settings are mm-dd-yyyy AM/PM on these sites, targeted at
people who do NOT use them!
My conclusion is: E-groups (Onelist.com) is just as bad as Be.Inc.; both
companies want to destroy ISO 8601 and to impose this medieval garbage on
the world. Maybe we should look for another provider of this kind.

If I could, I would have no truck with this company at all,

  Han

Based on my observation, mm/dd/yyyy is used in the editions of
the United States, Canada (English); China (!), Hong Kong (!), Taiwan
(!) of eGroups, not all editions. It is strange to use am/pm nearly
everywhere.
      Please take a look on the following I have gathered:

English: US, Canada: Sun 11/12/2000
English: UK, Australia, India, Singapore: Sun 12 Nov 2000
French: France, Canada: Dim 12 nov 2000
Chinese: China: Zhouri 11/12/2000 (!)
Chinese: Hong Kong, Taiwan: Xinqiri 11/12/2000 (!)

      So if you do not like mm/dd/yyyy, you can use a non-US edition
which does not use it. I consider eGroups is not as evil as you think
of spreading mm/dd/yyyy worldwide. But imposing it in China, Hong
Kong, Taiwan is an invasion of American "imperialism" to Chinese area
and interruption of Chinese culture. The only accepted way to write
dates in Chinese is in year month day order, which is in use in
editions of Korea and Japan.

Justin JIH

--- In ISO8601@egroups.com, "Han Maenen" <han.maenen@w...> wrote:
> I contacted them about this months ago, to no avail. They did not
bother to
> answer, well this IS an answer as far as I am concerned: E-groups
> (Onelist.com)wants the death of ISO 8601.
> This company has European websites in languages like French, German
and
> Italian, but what about the settings? Do they respect the
international ones
> there? NO! The settings are mm-dd-yyyy AM/PM on these sites,
targeted at
> people who do NOT use them!
> My conclusion is: E-groups (Onelist.com) is just as bad as Be.Inc.;
both
> companies want to destroy ISO 8601 and to impose this medieval
garbage on
> the world. Maybe we should look for another provider of this kind.
>
> If I could, I would have no truck with this company at all,
>
> Han
>
> ----- Original Message -----
> From: "Dave Clark" <dave.clark@s...>
> To: <ISO8601@egroups.com>
> Sent: Tuesday, 2001 January 23, 11:43
> Subject: [ISO8601] egroups date listing
>
>
> > I cannot believe I am the first to notice this, but....
> >
> > The date listing on the eGroups ISO8601 is in format mm/dd/yyyy.
Who can
> we get to fix this?
>
>  Dave Clark

On  2001-Jan-24  Pete Forman  <pete.forman@...>  wrote(>>>,>>,>):


[2001-Jan-25]



> Recently, g1smd@... writes:

>> On  2001-Jan-23  Dave Clark  <dave.clark@...>  wrote:

>>> Is anyone aware of standards on costweeks?

>>> My understanding was that they were an international standard, my
>>> enquiries to date suggest that they are internal to a company.
>>> My company use them for accounting and manufacturing processing,
>>> that are subsequently broken into cost periods.
>>> Ie. costweek 02/2001 is Sat 2001-01-06 to Fri 2001-01-12

>> Yes, ISO 8601 covers this.

> Strictly speaking it does not.  Weeks run from Mon to Sun only.  (I
> realize that you spelt out the details later in your post.)  Even if
> it does not matter to Dave if the weekend is counted in the wrong
> week, the ordinal number of the week may differ.


Sorry, poor wording on my part. ISO 8601 covers a date format that is based
on counting weeks, so a partial Yes to the question. However, as Pete now
points out, the week always starts with Monday in the ISO standard. So in
fairness to the question that actually mentioned the week starting with
Saturday, the answer strictly should be:  "No, the ISO 8601 standard does
not cover the week running from Saturday to Friday, but the ISO standard
does have a format based on counting weeks; however, the only allowed week
format is one that runs from Monday until the following Sunday."  Sorry for
any confusion.



>> Beware of JavaScript which numbers the months of the year from 0 to
>> 11. Who the hell decided on that idea?

> The same people who stored the year as tm_year = years since 1900 ;-)

> struct tm has been defined that way in Unix for many years now.  It
> was certainly well established in 1989.


I have seen the Unix way, and I don't like it. Doesn't it run out of numbers
for the date in 2038 or sometime thereabouts?. I have seen this mentioned in
many places, but didn't totally absorb the date, as I have nothing here that
will be affected. I will be affected if people out there don't fix their Web
servers and hole-in-the-wall cash machines. I guess it will be just like the
Year 2000 panic again, except many people who will be in work at that time,
are yet to be born. There's no point talking about it just yet, as it is too
far away, but I'll bet that people will try to flag it up five to ten years
beforehand, and then be totally ignored until the last year or so. However,
these types of machines may not be around by then anyway. Who knows?



>> ... which is still waiting to be published as the updated 2000
>> version.

> ISO 8601:2000 was published on 2000-12-21.  It may be purchased from
> <http://www.iso.ch> and no doubt the other places in due course.


Thank you for the information:

       THE NEW ISO 8601:2000 STANDARD WAS PUBLISHED ON 2000-12-21.

I think everyone on this email group had missed that fact. I don't follow
what comes directly out of ISO, I only get to look at the list of BRITISH
Standards documents. I have been looking every few months, for at least the
last two years expecting to see the 1998 revision published. I was surprised
to see nothing. The review and update of ISO 8601 took about three years.
The reviews and updates of standards seem to be taking longer and longer
these days. They used to republish to a strict 5 or 10 year timetable, but
that seems to be slipping more and more.

I will not be paying out for a paper copy for myself in the immediate
future. I hope that ISO will release it as a PDF document, like they did for
the previous version. That was free, but I don't expect it to continue as a
free download. If they charge a more reasonable fee for a PDF version,
compared to the prices of printed standards, then I will consider it.
Otherwise I can borrow a copy through several contacts. People who expect to
borrow a copy and then photocopy it, need not bother.. the standards that I
have seen, have nearly always been printed on Red paper so that you get a
totally black sheet out of the copier if you try it. I don't know if this is
unique to the British Standards, or if this is used in other countries as well.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>

<ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
<ftp://ftp.qsl.net/pub/g1smd/>


[2001-01-25]

.end

Han,
OK then, let's string 'em up!

(This means send them to the gallows. I didn't want to leave
an unexplained American idiom in this conversation ;-) )

I liked your example of the impact on the students.
tex


Han Maenen wrote:
>
> I am sorry, but I disagree. They are not ignorant. What makes me believe
> that what they are doing is intentional is that E-groups has sites in Europe
> in French, German and Italian with mm-dd-yyyy AM/PM settings. They work
> abroad and they do not know that these settings are not used there? At least
> they could have used the now obsolete European settings of dd-mm-yyyy 24
> hour on these sites. That would have convinced me of their good will.
>
> The other company, Be.Inc. has offices and probably production facilities in
> France. Nobody can make me believe that they are ignorant. Apple and
> Microsoft know about local settings and ISO 8601, Amiga knew about them too
> and I have to believe that Be.Inc. doesn't?
> No way, I remain where I stand and that is that companies that work abroad,
> like Be.Inc and Onelist.com, know about ISO 8601. If, however, they insist
> on bombarding European and other non-English speaking peoples with the US
> formats and even more, FORCING them to use these formats on pain of error
> messages and even system crashes, then I am convinced that they are trying
> to do away with ISO 8601 by fooling their international clients into
> accepting the settings used in the USA as the real global standard.
>
> Another indication is that if anybody contacts them on this issue they do
> not bother to answer.
>
> I remember from a class at university years ago, in the era of 286 computers
> and DOS, when the lecturer  HAD to instruct us to type in the US date and
> time when starting the computer, or the computer would stop in its tracks
> with an error message. Then something had to be written down on paper or on
> a word processor and a student asked if the date had to be written the same
> way as he had done when switching on the computer. No, said the lecturer,
> you can do it in the format you are accustomed to. I am grateful that the
> lecturer limited the damage, but this event also showed me the subtle ways
> in which people can be made to adopt something.
>
> The only companies which can be excused because of ignorance are those that
> work entirely within the USA and these were not my target.
>
> Han
>
> ----- Original Message -----
> From: "Tex Texin" <texin@...>
> To: <ISO8601@egroups.com>
> Sent: Wednesday, 2001 January 24, 08:44
> Subject: Re: [ISO8601] egroups date listing
>
> > Seems a bit strong to consider the ignorance of companies that do not use
> 8601, as hostile and wanting to destroy 8601.
> They are just being ignorant. Am I missing something?
>  tex
>
>  Han Maenen wrote:
>
>  I contacted them about this months ago, to no avail. They did not bother to
> answer, well this IS an answer as far as I am concerned: E-groups
> (Onelist.com)wants the death of ISO 8601.
> This company has European websites in languages like French, German and
> Italian, but what about the settings? Do they respect the international ones
> there? NO! The settings are mm-dd-yyyy AM/PM on these sites, targeted at
> people who do NOT use them!
> My conclusion is: E-groups (Onelist.com) is just as bad as Be.Inc.; both
> companies want to destroy ISO 8601 and to impose this medieval garbage on
> the world. Maybe we should look for another provider of this kind.
>
> If I could, I would have no truck with this company at all,
>
>  Han
>
> ISO8601 Community email addresses:
>   Post message: ISO8601@onelist.com
>   Subscribe:    ISO8601-subscribe@onelist.com
>   Unsubscribe:  ISO8601-unsubscribe@onelist.com
>   List owner:   ISO8601-owner@onelist.com
>   URL : http://www.onelist.com/community/ISO8601

--
According to Murphy, nothing goes according to Hoyle.
--------------------------------------------------------------------------
Tex Texin                      Director, International Business
mailto:Texin@...      +1-781-280-4271 Fax:+1-781-280-4655
Progress Software Corp.        14 Oak Park, Bedford, MA 01730

http://www.Progress.com        #1 Embedded Database

Globalization Program
http://www.Progress.com/partners/globalization.htm
---------------------------------------------------------------------------