The latest release of
http://www.exit109.com/~ghealton/y2k/yrexamples.html is now available
for use and review.

Summary: General summary of calendars, dates, and times from past to
the present. This includes details on using the ISO 8601 standard in
and out of computers. It ends with information for software
developers wanting to properly use dates and times.

Note the shortcut hyperlink at the top of the page that takes readers
directly to the section on ISO 8601.

TO: Gilbert HEALTON
	 Peter HAAS
	 Peter NELSON

Gilbert you have carried out a great deal of work over the years particularly
with
your analysis of how dates are used by different operating systems.  Your web-
page is an excellent explanation of the history of Calendars and provides some
very useful links especially the Time Zones.

PERMISSION FOR PERMANENT LINK

Thank you for explanations and contributions to a better understanding of
dates and time issues in relation to ISO 8601.

With your permission we would like to include those explanations as permanent
links on the proposed Electronic Information Interchange [EII] Date structure so
that people no longer have to key in dates or use drop down menus.
http://www.halisa.net/cpt/d/AS2002.htm

TIME & DATE ICONS, HOT-KEYS OR TOOL-BAR

There obviously needs to be a standard key for calling up a date - like cut
{Ctrl
C} and paste {Ctrl V}.

Perhaps Ctrl D be suitable for calling up a rolling 12 month Date menu and Ctrl
T
for calling up a Time clock for all E-business applications.

There may be Date tool-bar, hot-key or icon so that a mouse can be used to
select the whole date.

What do you think ?

FORMULA FOR CALCULATING TIME

There is obviously a formula for calculating time in relation to longitude and
latitude.

As cars now have inbuilt GPS systems they must use some way of keeping the
car clock in sync as you drive through different time zones.

Does anyone know how they do it ?  And could it be modified for E-business
applications ?

NEXT STEPS

All feedback appreciated

regards

Stephen GOULD
Projects Co-ordinator
OPEN INTERCHANGE CONSORTIUM
15:59 U 2002/03/03 Syd 2089

E: sggould@...
T: (02) 9953-3583
W: http://www.oic.org/3a4a.htm


On 2 Mar 02, at 2:03, g_healton wrote:

> The latest release of
> http://www.exit109.com/~ghealton/y2k/yrexamples.html is now available
> for use and review.
>
> Summary: General summary of calendars, dates, and times from past to
> the present. This includes details on using the ISO 8601 standard in
> and out of computers. It ends with information for software
> developers wanting to properly use dates and times.
>
> Note the shortcut hyperlink at the top of the page that takes readers
> directly to the section on ISO 8601.
>
>
>
>

On 2002-Feb-26 Stephen Gould wrote(>):


[2002-Mar-08]


> Ian has pointed out in his e-mail on 2001 Jan 14 that
> very few XML books refer to the issue of ISO 8601.
> We are trying to address that issue by involving the
> XML development groups around the world.

As it happens I did another quick review of current titles
in that same bookshop a few weeks ago; that is, one year on
from the initial review. However, I had not yet got around
to writing about it.

A lot more books do now include some information on this
topic. One point that I made last year, was that many books
mentioned ISO 3166, 4217, etc, but not the ISO 8601 Date
and Time standard. I also said that many books gave date
examples in the wrong format. Some books did use the correct
format, but didn't explain how to read the format.

This year, things have improved a little; though it is
interesting to note that many still did not get the correct
name for ISO (which is the International Organisation for
Standardisation). There are some hilariously incorrect
examples. If they can't get something really simple correct,
then how can we trust anything else in the book?

There are still books with wrong examples, showing a non-ISO
date format, like 12/31/00, or an incorrect attempt at an ISO
format date, like 2001-1-6. Some books give an example that
is in the correct format, but give no explanation of how the
format works. Some others refer to the wrong standard number,
in a typo, ISO 8061 and 6801 being two examples that I found.

There has been an improvement in the last year, but the quality
of information is still not good enough. Last year much less
than 10% of books got it right. This year, perhaps 30 to 40%
have made a reasonable effort.



> Do the XML & E-commerce developers think ISO 8601 is the
> way to go ?

Undoubtably, as a subset of allowed ISO 8601 formats appears
in the vast majority of schemas. The W3C Note on DateTime has
had a big effect here. Also the number of useful web sites
giving relevant and more detailed information now available,
means that there should be no-one that says that they cannot
find any information on this subject. Don't forget that ISO
8601 defines a large amount of date styles following a list
of simple rules. Developers will need to pick, define, and
document the exact formats that they are going to use in
their application.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

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


[2002-03-08]

.end

On 2002-Feb-27 Stephen Gould wrote(>):


[2002-Mar-08]


> ISO 8601 is too wide in how it can be interpreted by software
> developers.

This is why some organisations have printed a 'short list'
of formats that are acceptable. The most well known is the
W3C 'Note' that many sites provide a link to. ISO 8601 defines
a method for the writing of dates and times, with varying
precision, optional separators, and truncation of data. There
is no single 'ISO' format. Users need to define and document
the exact syntax of the format(s) that they are going to use.



> [SNIP]

> You can either
> 1 allow the end user to type the required date or
> 2 provide a standard drop down menu that
>  automatically places the date
>  in the right ISO 8601 format

> However most SMEs do not have IT Departments they rely on
> software developers.

> This is why we are proposing a standard ISO 8601 format drop
> down menu for SME ebXML software developers.

Sounds like a reasonable idea.



> Most SMEs when they are setting up their systems do not put in
> the time differential into their e-mail software programs.

It would be nice for everyone to standardise on the UTC Time
Zone. I find it disconcerting to write a message at 20:00 and
receive a reply timed 16:00 the same day. Looking further I
then find my message was sent at 20:00+0000, and the reply is
stamped 16:00-0500. I am reasonably happy with this. It is
logical, but still confuses the general public big time.



> The National Telecoms all provide telephone books with the time
> differentials for each region.  Microsoft provides this as part
> of the Windows operation system.

The problem is that these differentials are constantly changing
due to political decisions. There is also the problem of 'Summer'
or 'Daylight Saving' Time Zones. Different countries move on
different dates. These dates are not fixed far into the future,
are also subject to a change of political decision. Also note
that the Northern and Southern hemisphere apply it in anti-phase.
There is an ISO standard, that gives time zones a name, and
association with a geographical location. However, it would
still not be clear to someone outside the US to know exactly
what geographical area would be covered by 'America/New_York',
or what the default name would be for a US time zone that is,
under ISO 8601, '-0600' from UTC.



> Perhaps a location code is required for E-business applications
> to calculate the difference between GMT and local time.  This
> location code could be provided by the ISP as part of the service.
> This could be the zip code in the US or postcode in UK and
> Australia.  It is part of the UN/EDIFACT address structure.

Please do not refer to GMT. GMT is obsolete. Only use UTC now.
It would be far wiser to do business in UTC, and let the end user
translate UTC data back into a local time. That is, do not worry
about the local time at the other end of the transaction, use
UTC for everything.



>    [SNIP]

>>   [SNIP]

>>>  [SNIP]

>>>> [SNIP]


  PLEASE DO NOT BLOCK QUOTE ALL PREVIOUS MESSAGES IN A THREAD.

  THEY ARE ARCHIVED AND THREADED ON THE YAHOO GROUPS WEB SITE.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

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


[2002-03-08]

.end

[2002-Mar-10]


According to the document located at:
<http://www.uninfo.polito.it/TC154/TC154public/154n384_154-18_res.pdf>
there was a request that the ISO 8601:2000 standard should
be placed in the public domain, in much the same way that
the earlier ISO 8601:1988 standard was made available for
free download from sometime around 1997, until early 2001,
on the ISO web site. This has never happened. I know that
several people on this mailing list requested this, but
all met with a negative response. It is interesting to see
that some people within ISO had already requested this, but
it was obviously declined, as only draft copies have been
made available.


> Document ISO/TC 154   N384   Page 7 of 7.

> Item 206:
> ISO/TC 154 resolves to request ISO/TMB to put ISO 8601:2000,
> "Representation of dates and times", into the public domain.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

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


[2002-03-10]

.end

[2002-Mar-10]


Both the 'Files' and 'Bookmarks' sections of the ISO 8601
YahooGroups web site have been updated today.

Please take a look sometime. More entries are still required.


Please take action on the various comments in the message
at:  <http://groups.yahoo.com/group/ISO8601/message/356>
noting the correction of address in the follow-up message
at:  <http://groups.yahoo.com/group/ISO8601/message/359>.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

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


[2002-03-10]

.end

[2002-Mar-10]


There are several additional places to find copies of the
ISO 8601:1988 standard as a PDF file.

These are located at:
  <http://www.carc.aist.go.jp/nlwww/i-content/gda/8601.pdf>
  <http://www.pvv.ntnu.no/~nsaa/8601.pdf>.

The description for both of these files is:
ISO 8601:1988 [Original Version: 1988-06-15] (Text/PDF: 1.2MB).


Both the 'Files' and 'Bookmarks' sections of the ISO 8601
YahooGroups web site have been updated with this extra
information.

Is anyone aware of any other unlisted web or ftp sites,
with these files?



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

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


[2002-03-10]

.end

[2002-Mar-10]


There is another FTP site that has been found, which contains
PDF copies of the various versions of the ISO 8601 standard,
from the published 1988 version through the various draft
versions issued in 1997, 1998, and 2000.


These are located at:

  ----------------------------------------
<ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/iso/iso8601%3A1988E.pdf>
[iso8601:1988E.pdf]                               1 MB       1998-11-15
  ----------------------------------------
<ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/iso/iso8601-1988.pdf>
[iso8601-1988.pdf]                                1 MB       2001-12-17
  -----------------------------------------
<ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/iso/iso-iec-8601-1988-ReprD
atesAndTimes.pdf>
[iso-iec-8601-1988-ReprDatesAndTimes.pdf]         1 MB       2001-12-23
  -----------------------------------------
<ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/iso/iso8601%3A1997-v3.pdf>
[iso8601:1997-v3.pdf]                          89.8 kB       1998-11-15
  -----------------------------------------
<ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/iso/iso-iec-8601-draft03-Re
prDatesAndTimes.pdf>
[iso-iec-8601-draft03-ReprDatesAndTimes.pdf]   89.8 kB       2001-12-23
------------------------------------------
<ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/iso/iso8601%3A1997-v4.pdf>
[iso8601:1997-v4.pdf]                          71.3 kB       2001-11-09
  -----------------------------------------
<ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/iso/iso8601%3A2000E.pdf>
[iso8601:2000E.pdf]                           192.0 kB       2001-12-10
  -----------------------------------------
<ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/iso/iso8601%3A2000-154n362.pdf>
[iso8601:2000-154n362.pdf]                    185.1 kB       2001-12-10
  -----------------------------------------


The 'Files' and 'Bookmarks' sections of the YahooGroups web site
will be updated, sometime later, with this new information.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

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


[2002-03-10]

.end

Hi Ian  - thank you for your comprehensive response - my replies are included.

In summary the key issues include:

1 How do we assist software developers to use a standard date code
	 especially for initial E-commerce negotiations

2 How and who liaises with GPS and GIS developers so that local maps can
	 be provided to show locations for timezone changes

3 How quickly can this be pulled together and who funds it ?

Any response most welcome

regards

Stephen GOULD
ebXML Representative
OPEN INTERCHANGE CONSORTIUM

06:38 M 2002/03/11 Syd 2089
http://www.halisa.net/G/C/HINGCAH2.htm

On 8 Mar 02, at 23:54, g1smd@... wrote:

> On 2002-Feb-27 Stephen Gould wrote(>):
>
>
> [2002-Mar-08]
>
>
> > ISO 8601 is too wide in how it can be interpreted by software
> > developers.
>
> This is why some organisations have printed a 'short list'
> of formats that are acceptable. The most well known is the
> W3C 'Note' that many sites provide a link to. ISO 8601 defines
> a method for the writing of dates and times, with varying
> precision, optional separators, and truncation of data. There
> is no single 'ISO' format. Users need to define and document
> the exact syntax of the format(s) that they are going to use.
>
In E-commerce that is going to make it very difficult to set up a quick
electronic system whereby someone would like to try out a product
or service before they commit to an order.

People are never going to get past the negotitation stage if they have to agree
which exact format they are using before they can start negotiations.

There needs to a single format to start the ball rolling for negotiations.
>
>
> > [SNIP]
>
> > You can either
> > 1 allow the end user to type the required date or
> > 2 provide a standard drop down menu that
> >  automatically places the date
> >  in the right ISO 8601 format
>
> > However most SMEs do not have IT Departments they rely on
> > software developers.
>
> > This is why we are proposing a standard ISO 8601 format drop
> > down menu for SME ebXML software developers.
>
> Sounds like a reasonable idea.
>
How do we implement it ?

>
>
> > Most SMEs when they are setting up their systems do not put in
> > the time differential into their e-mail software programs.
>
> It would be nice for everyone to standardise on the UTC Time
> Zone. I find it disconcerting to write a message at 20:00 and
> receive a reply timed 16:00 the same day. Looking further I
> then find my message was sent at 20:00+0000, and the reply is
> stamped 16:00-0500. I am reasonably happy with this. It is
> logical, but still confuses the general public big time.
>
>
This is a real problem isn't - now is the time we have to enable software
developers to incorporate it in their software as an add-on module.
>
> > The National Telecoms all provide telephone books with the time
> > differentials for each region.  Microsoft provides this as part
> > of the Windows operation system.
>
> The problem is that these differentials are constantly changing
> due to political decisions. There is also the problem of 'Summer'
> or 'Daylight Saving' Time Zones. Different countries move on
> different dates. These dates are not fixed far into the future,
> are also subject to a change of political decision. Also note
> that the Northern and Southern hemisphere apply it in anti-phase.
> There is an ISO standard, that gives time zones a name, and
> association with a geographical location. However, it would
> still not be clear to someone outside the US to know exactly
> what geographical area would be covered by 'America/New_York',
> or what the default name would be for a US time zone that is,
> under ISO 8601, '-0600' from UTC.
>
This is why we believe that it should be links with the Global Positioning
System
[GPS] or Geographical Information System [GIS] so that people can find out
exactly where the location is if they want to locate the company.  Now is the
time that it has to be considered.
>
>
> > Perhaps a location code is required for E-business applications
> > to calculate the difference between GMT and local time.  This
> > location code could be provided by the ISP as part of the service.
> > This could be the zip code in the US or postcode in UK and
> > Australia.  It is part of the UN/EDIFACT address structure.
>
> Please do not refer to GMT. GMT is obsolete. Only use UTC now.
> It would be far wiser to do business in UTC, and let the end user
> translate UTC data back into a local time. That is, do not worry
> about the local time at the other end of the transaction, use
> UTC for everything.
>
>
>
> >    [SNIP]
>
> >>   [SNIP]
>
> >>>  [SNIP]
>
> >>>> [SNIP]
>
>
>  PLEASE DO NOT BLOCK QUOTE ALL PREVIOUS MESSAGES IN A THREAD.
>
>  THEY ARE ARCHIVED AND THREADED ON THE YAHOO GROUPS WEB SITE.
>
>
>
> Cheers,
>
> Ian.
>
>
> <mail://g1smd@amsat.org>
>
> <http://www.qsl.net/g1smd/>
> <http://home.freeuk.net/g1smd/>
> <http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
> <http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>
>
> <ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
> <ftp://ftp.qsl.net/pub/g1smd/>
>
>
> [2002-03-08]
>
> .end
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Ian Galpin wrote:
>According to the document located at:
><http://www.uninfo.polito.it/TC154/TC154public/154n384_154-18_res.pdf>
>there was a request that the ISO 8601:2000 standard should
>be placed in the public domain, in much the same way that
>the earlier ISO 8601:1988 standard was made available for
>free download from sometime around 1997, until early 2001,
>on the ISO web site. This has never happened. I know that
>several people on this mailing list requested this, but
>all met with a negative response.

    This is true.  Below is the negative response that I received from
an ISO representative, in response to my queries of 2001-02-14 and
2001-02-22 sent to <copyright@...>:

>Date: Mon, 19 Mar 2001 17:53:12 +0100
>From: "Chabot Jacques-Olivier" <chabot@...>
>Organization: ISO
>To: Aron Roberts <aron@...>
>CC: Nicolas Fleury <fleury@...>, Sue Jenner <jenner@...>
>Subject: Re: Request for no-cost publication or redistribution
>rights to ISO 8601
>
>Dear Mr. Roberts,
>
>This is true that ISO 8601:1988 has been accessible from various
>website including the ISO website: the reason was the Y2K
>foreseeable problems. The new edition is now published and will not
>be available for free neither from the ISO webstore nor from any
>others. Consequently my reply to your question is NO. Also I have to
>give you a negative reply to your second question regarding the
>purchase of one copy for further free distribution. The reason is
>that ISO and its members are to a large extend financed via the
>revenue derived from the sales of standards and related
>publications. Free standards would mean at the end of the day no
>more standard which would be detrimental to the entire community.
>
>Thank you for your interest in ISO.
>
>Best regards
>
>Jacques-Olivier Chabot

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

g1smd@... writes:
  > It would be nice for everyone to standardise on the UTC Time
  > Zone. I find it disconcerting to write a message at 20:00 and
  > receive a reply timed 16:00 the same day. Looking further I
  > then find my message was sent at 20:00+0000, and the reply is
  > stamped 16:00-0500. I am reasonably happy with this. It is
  > logical, but still confuses the general public big time.

That seems to me to be a limitation of your email client.  The
information is there for the UTC to be calculated and displayed.
My personal preference is to show local time by default and UTC
on request.

The local time of a sender is useful to be able to guess when they
might read a reply.
--
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman@...    -./\.-   opinion of Schlumberger, Baker
http://petef.port5.com           -./\.-   Hughes or their divisions.

On 2002-03-12 10:16:31 +0000, Pete Forman wrote:
> g1smd@... writes:
>  > It would be nice for everyone to standardize on the UTC Time
>  > Zone. I find it disconcerting to write a message at 20:00 and
>  > receive a reply timed 16:00 the same day. Looking further I
>  > then find my message was sent at 20:00+0000, and the reply is
>  > stamped 16:00-0500. I am reasonably happy with this. It is
>  > logical, but still confuses the general public big time.
>
> That seems to me to be a limitation of your email client.  The
> information is there for the UTC to be calculated and displayed.
> My personal preference is to show local time by default and UTC
> on request.
>
> The local time of a sender is useful to be able to guess when they
> might read a reply.

Just add a day to the email's date and you'll know when someone
might read a reply.

Most people read mail periodically every day.

There is no need for local times in the Internet.

Standardizing on the UTC Time is the right move.

Eduardo,
That may be true for you, but it is not true for everyone. I do a lot of
international mail, and often it is valuable to assess if a
correspondent is in night time, day time, meal time, or whatever so I
can know if a response is coming in 1 hr or 10 hrs. Some projects depend
on frequent turn-around.

So you are right, the internet does not need local time, but people do.
Mail should standardize on UTC, but user interfaces should give people
times in local time, until people start using UTC in their daily life.
I would not object to that change either, but I do object to my mail
program driving the change.

tex

Eduardo Pérez wrote:
> > The local time of a sender is useful to be able to guess when they
> > might read a reply.
>
> Just add a day to the email's date and you'll know when someone
> might read a reply.
>
> Most people read mail periodically every day.
>
> There is no need for local times in the Internet.
>
> Standardizing on the UTC Time is the right move.

--
-------------------------------------------------------------
Tex Texin                    Director, International Business
mailto:Texin@...    the Progress Company
Tel: +1-781-280-4271         http://www.progress.com
-------------------------------------------------------------
Find out about Globalization Empowerment for Progress users
http://www.progress.com/consulting/globalization_empowerment_solutions.htm
mailto:global-empowerment@...
For a compelling demonstration for Unicode:
http://www.geocities.com/i18nguy/unicode-example.html

Service Announcement

    Groups will be down for scheduled maintenance

    Friday 2002 Mar 15 21:00 PST (UTC-0800).

    We expect to restore service the morning of Sunday Mar 17.



   More Info:

   http://groups.yahoo.com/local/service.html

It is not a standard. It is a note.

Having said that, can you make your point more clear? Are there some
particular issues you want to address?
tex


--
-------------------------------------------------------------
Tex Texin                    Director, International Business
mailto:Texin@...    the Progress Company
Tel: +1-781-280-4271         http://www.progress.com
-------------------------------------------------------------
Find out about Globalization Empowerment for Progress users
http://www.progress.com/consulting/globalization_empowerment_solutions.htm
mailto:global-empowerment@...
For a compelling demonstration for Unicode:
http://www.geocities.com/i18nguy/unicode-example.html

[2002-Mar-22]


There are several additional places to find draft copies of the
ISO 8601:2000 standard as a PDF file:

  <http://anubis.dkuug.dk/jtc1/sc22/wg20/docs/n806-fdis8601.pdf>
  The description for this file is:
  ISO 8601:2000 [Late Draft: 2000-10-05] (Text/PDF: 192KB).

  <http://www.pvv.ntnu.no/~nsaa/8601v2000.pdf>
  The description for this file is:
  ISO 8601:2000 [Final Draft: 2000-12-15] (Text/PDF: 185KB).


Both the 'Files' and 'Bookmarks' sections of the ISO 8601
YahooGroups web site have been updated with this extra
information.

Is anyone aware of any other unlisted web or ftp sites,
with these files?



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

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


[2002-03-22]

.end

[2002-Mar-24]


I found this information on the ISO web site:


> Ref.: 815
> 2002 February 06

> Suite of over 100 information technology standards available
> online at reduced price.

> A collection of over 100 information technology standards has
> just been made available online at a special reduced rate during
> a market trial to promote the use of IT standards developed by
> ISO (International Organization for Standardization) and IEC
> (International Electrotechnical Commission).

> The standards comprise an integrated and comprehensive collection
> chosen from the output of the joint technical committee, ISO/IEC
> JTC 1, Information technology. They are available in electronic
> format, online at a special flat rate of 44 Swiss francs from the
> end of January 2002 until the end of the year.

[SNIP]

> On completion of the trial, the ISO/IEC JTC 1 Market Trial Project
> Team will study the results and opinions gathered and deliver its
> recommendations to ISO and IEC Councils in the first half of 2003.



Unfortunately, this does NOT include ISO 8601:2000. However, as ISO
are obviously not making enough money selling their standards now
that so many other bodies (IETF, W3C etc) are developing many IT and
Internet standards for free, perhaps some other ISO standards will be
selected in a future offer. Maybe ISO 8601 will be included later on?

Keep on looking.



Cheers,

Ian.


<mail://g1smd@amsat.org>

<http://www.qsl.net/g1smd/>
<http://home.freeuk.net/g1smd/>
<http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
<http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/>

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


[2002-03-24]

.end

In ISO8601 group hjwoudenberg wrote:

> Recommendations (not standards) from the IETF,
> Who agrees with this?



[2002-Mar-24]


Can you make your point more clear? Are there some
particular issues you want to address?



Cheers,

Ian.


[2002-03-24]

.end

ISO International Standards

5.3.1.3 Representation of decimal fractions

".. the decimal fraction shall be divided from the integer part by the
decimal sign specified in ISO 31-0: i.e. the comma[,] or full stop [.].  Of
these, the comma is the preferred sign.  (Long before ISO,  SQL used a period
for the fraction.  To change all the SQL servers in the world to conform to
ISO would be a major task.  Common scenic says use the period.)

5.4.2 Complete representation

" The character [T] shall be use as the time designator"

Note.  By mutual agreement of the partners in information interchange the
character [T] may be omitted....."
When using the combination, how many of you use the "T" for reports and
screen displays?  How many use the blank?  Why?  Do  you always convert to
the [T] on the file or for international comunication?

4.4 Characters used in the representations

Note 1   Where the upper characters are not available lower case characters
may be used.   Does your software treate the time designator as equal if it
is [T, t or blank)?


5.2.1.2 Representaion with reduced precision
c) A specific century
Basic format YY             Example 19
5.2.1.3 Truncated representation
c) A specific year in the implied century
Basic format -yy             Example -85

Is this clear to everyone?

5.3.2 Midnight
        Basic Format                Extended format
a)          000000                   00:00:00  (the begioning of a day)
b)          240000                   24:00:00   (The end of a day)

Note 1 Midnight will normally be represetned as [0000] or [2400]
Note 3 The end of one day [2400] coincide with [0000] at the start of the
next day, e.g. 2400 on 1985 April 12 is the same as 0000 on 1985 April 13.

You agree?

Annex A
Relationship to ISO 2014, 2015, 2711, 3307 and 4031

For times, use of the 24-hour timekeeping systems is now so common
(particularly in view of the wide availability and use of digital watches)
that seperators to aid human interpretation are no longer necessary, but are
included as options.

Do you agree?

The relational database model was originally developed by Dr. E.F. Codd in
the early 1970s. The SQL language was originally developed by IBM in a
prototype relational database management system,

Today SQL is widely implemented and is accepted as the industry standard
database access language.

OK, but SQL existed for a rather short period in the overall scheme of
things, and RDBMS is a small percentage of the software that exists
today (compare to word processing for example), so it makes a poor
precedent.

On the other hand, writing numbers with commas goes back to 1617
(proposed by John Napier) and is used by a large part of the world,
which is reasonable motivation for supporting commas.

However, it's a silly debate since:
a) 8601 let's you use either.
b) Although SQL uses the full stop for time in SQL language, time can be
displayed to users or input from users either way (decimal or comma).
c) No one is asking SQL to change anything. (The moreso since SQL date
and time is based on ISO 8601, I believe.)

tex

hjwoudenberg@... wrote:
>
> The relational database model was originally developed by Dr. E.F. Codd in
> the early 1970s. The SQL language was originally developed by IBM in a
> prototype relational database management system,
>
> Today SQL is widely implemented and is accepted as the industry standard
> database access language.

--
-------------------------------------------------------------
Tex Texin                    Director, International Business
mailto:Texin@...    the Progress Company
Tel: +1-781-280-4271         http://www.progress.com
-------------------------------------------------------------
Find out about Globalization Empowerment for Progress users
http://www.progress.com/consulting/globalization_empowerment_solutions.htm
mailto:global-empowerment@...
For a compelling demonstration for Unicode:
http://www.geocities.com/i18nguy/unicode-example.html

hjwoudenberg@... wrote a rather confusing message quoting fragments
of ISO 8601 with additional comments and questions which at least open
the possibility of further discussion.

> ISO International Standards
>
> 5.3.1.3 Representation of decimal fractions
>
> ".. the decimal fraction shall be divided from the integer part by the
> decimal sign specified in ISO 31-0: i.e. the comma[,] or full stop [.].  Of
> these, the comma is the preferred sign.  (Long before ISO,  SQL used a period
> for the fraction.  To change all the SQL servers in the world to conform to
> ISO would be a major task.  Common scenic says use the period.)

Half the world use full stop (English speaking countries mostly) and half
the world use comma (rest of Europe and countries under their influence).
ISO allow both but pick one as "preferred" which seems sensible to me.  I'd
prefer use of period (full stop) for decimal point partly because I'm
English but mostly because comma is very commonly used as a list separator
but it's hardly worth getting worked up about it.

> 5.4.2 Complete representation
>
> " The character [T] shall be use as the time designator"
>
> Note.  By mutual agreement of the partners in information interchange the
> character [T] may be omitted....."
> When using the combination, how many of you use the "T" for reports and
> screen displays?  How many use the blank?  Why?  Do  you always convert to
> the [T] on the file or for international comunication?

I think that when you use the blank you are really writing two items - a date
and then a time.  I'd normally use this format for display though in a few
contexts I might include the 'T' - e.g., in a mailing list regarding satellite
observation I'm in where UTC, astronomical date/time formats and various
abbreviated codes are already in wide use.

I'm currently writing a program for scoring certain sports events.  Display
is in formats like "2002-03-25 11:16:13.25" whereas the data is stored in
a CSV file as "2002-03-25T11:16:13.25".  This does not require a specific
conversion as such as all data is held internally within the program as a
set of separate integer values (year, month, day, hour, minute, second,
millisecond).

> 4.4 Characters used in the representations
>
> Note 1   Where the upper characters are not available lower case characters
> may be used.   Does your software treate the time designator as equal if it
> is [T, t or blank)?

This is pretty theoretical as I can't think of any contexts where lower case
letters are available but upper case are not.  Even the old 5 bit Baudot code
teletypes had upper case rather than lower (or at least didn't distinguish
case at all).  Hardly worth worrying about in a decade when one can hope
that Unicode will enter widespread use.

> 5.2.1.2 Representaion with reduced precision
> c) A specific century
> Basic format YY             Example 19
> 5.2.1.3 Truncated representation
> c) A specific year in the implied century
> Basic format -yy             Example -85

This one seems a bit silly to me.  I think YY should be the year in
century to match common practice.  Writing century numbers alone
doesn't seem a major requirement and it seems a waste of a compact
notation.  On the other hand, anybody who writes two digit year
numbers is asking for trouble.

> Is this clear to everyone?
>
> 5.3.2 Midnight
>        Basic Format                Extended format
> a)          000000                   00:00:00  (the begioning of a day)
> b)          240000                   24:00:00   (The end of a day)
>
> Note 1 Midnight will normally be represetned as [0000] or [2400]
> Note 3 The end of one day [2400] coincide with [0000] at the start of the
> next day, e.g. 2400 on 1985 April 12 is the same as 0000 on 1985 April 13.
>
> You agree?

Yes.  I'd go further and allow notations like 25:30 on 1985 April 12 to
mean the same as 01:30 on 1985 April 13.  Very useful for things like
train or TV schedules which often start a new "day" at around 06:00.

A bit like the advertising joke about Kronenberg 1665 (beer) which is
interpretted as five past five.

>
> Annex A
> Relationship to ISO 2014, 2015, 2711, 3307 and 4031
>
> For times, use of the 24-hour timekeeping systems is now so common
> (particularly in view of the wide availability and use of digital watches)
> that seperators to aid human interpretation are no longer necessary, but are
> included as options.
>
> Do you agree?

Yes.  I've never heard of any confusion being caused because of train
timetables or TV listings missing out the colon between the hours and
the minutes.  If the seconds or date are being specified as well it's
easier to parse the whole expression if separators are present.

Ed Davies.

I think looking at the effort required to implement is important.

What percentage of the software in the industry will determine that two dates
are equal if the only difference is the comma and the period?  I would like
to hear from others.

I think it would be best to have one option.  What do other think?

This has been my purpose.  I would like to hear from others!

hjwoudenberg solicited:

>You can find his presentation on line
>He has given it to the 16th 18th and 20th UNICODE conferences
>Search Tex Texin Date Time.

>Tell him what you think of it?
================================

I am always glad to get feedback, although this note from hjwoudenberg
was not at my direction. There is a version hosted at:

http://www.unicode.org/iuc/iuc18/papers/a13.ppt

I will be giving the (updated) paper in Dublin at the 21st conference in
May.

The paper does not list the ambiguities with either period and comma or
"T" and space as an issue, since I do not consider it a difficulty for
implementors.

tex

--
-------------------------------------------------------------
Tex Texin                    Director, International Business
mailto:Texin@...    the Progress Company
Tel: +1-781-280-4271         http://www.progress.com
-------------------------------------------------------------
Find out about Globalization Empowerment for Progress users
http://www.progress.com/consulting/globalization_empowerment_solutions.htm
mailto:global-empowerment@...
For a compelling demonstration for Unicode:
http://www.geocities.com/i18nguy/unicode-example.html