On 2000-Jan-31 Jan Bostrom wrote(>>,>):


[2000-Feb-01]


> On 2000-01-29 Ian Galpin wrote:
>
>> [Snip]     As long as the statement 'COUNTRY=086' or
>> 'COUNTRY=088' existed in the 'CONFIG.SYS' file, dates were displayed as
>> YY-MM-DD in the DOS 'DIR' listings, in the 'DATE' command, and so on. These
>> were country settings for Korea and Japan (I think), and I always used them
>> in place of '044' which was supposedly the 'correct' one for the UK.
>> Additionally, when using '086' or '088' all times were displayed in 24-hour
>> format (rather than 12-hour am/pm).
>>
>> Microsoft have made some unfortunate changes since then. Nowadays, if you
>> select these country options for the DOS that runs under Windows 95, you
>> still get the dates in YY-MM-DD format, but the time is displayed in 12-hour
>> am/pm format.


> Try COUNTRY=046 instead. That's Sweden and you will get both YY-MM-DD
> date format and 24 hour time format. The only thing I do not
> understand is why it uses "." as a time separator when the Swedish
> standard (which is identical to ISO 8601) prescribes a ":".


I initially rejected 'COUNTRY=046' for this very reason. Many other '03x'
and '04x' COUNTRY numbers also use YY MM DD, but also with 'unsuitable
punctuation' such as  YY.MM.DD  or  YY,MM,DD  or  HH,MM  etc. Additionally,
the rules seemed to change with each new release of DOS: 5.0, 6.0, 6.10,
6.22, etc; the individual country settings changed every time a new version
of DOS arrived. Microsoft haven't made a very good job of things. I would
like to see an 'International' country added to the list, one which complies
with the International Standards, rather than trying to use Regional
Settings that are confusing, ambiguous, and not agreed by anyone. The
available 'settings' for countries like '044' and '046' are merely those
settings that Microsoft believe that users in each of those countries need.
Perhaps we can convince them that the settings they have provided are NOT
what we require?

At least in the Control Panel (Regional Settings) of Windows 95/98 it is
very easy to change the date format to 'yyyy-MM-dd' for the Short Format
Date, and to 'yyyy MMM dd, ddd' for Long Format Date. Again, Microsoft ought
to provide these options as standard in the drop-down list for each country,
since everyone (except Microsoft it seems!) has now signed up to ISO 8601.
However, you won't find Year-Month-Day options listed against most country
options. Pity!

Anyone know how LINUX handles these things? Apparently it's a doddle on all
things Apple!



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-02-01]

.end

Do you have -- or can you point to -- a concise, compelling
statement of why a software vendor should adopt ISO 8601 in their
products?

    In addition, can you offer suggestions as to why an operating
system vendor should support ISO 8601, and how they might best to do?

    (For instance, should the vendor provide an easily selectable
"International date/time standard (ISO 8601)" option in a date
formats control panel or other such interface?  Should they provide
application programming interfaces which include conversions between
other date formats and the ISO 8601 text formats?  Or?)

    I'd like to submit or adapt such a statement/suggestions in a
submission to Apple Computer, Inc.'s developer feedback address
regarding ISO 8601 support in Apple's forthcoming Macintosh operating
system, Mac OS X.

Many thanks in advance,

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

Hi,

Does anyone know how I can set Linux to display dates in the ISO8601 short date
format?
Ideally this would be at the command prompt level but failing that, if it is
possible to change it in the GUI (GNOME, KDE or X11) that would be a step in the
right direction.
I should say that I am a bit of a novice when it comes to Linux, but I can not
find any documentation that mentions changing the date format.
Any feedback would be greatly appreciated.

Cheers,
Ray.

Raymond Robertson
Datacom Networks
raymond.robertson@...

I have not been able to find a package/class for Java that contains a
parser that can parse a 8601 date/time string.

The Java SimpleDateFormat will allow you to specify a particular
format - but not one that recognizes the various 8601 formats. e.g.
parse  "2000-03-01T01:00:00", "2000-03-01", "20000
301T01:00:00-09:00", etc. without basically doing a complete
pre-parse.

Anyone know of a Java class for this? I can't be the first person to
run into this.

Thanks,

Craig Pratt
pratt@...

In the message "ISO8601 parser/formatter for Java", dated 2000-03-02,
Craig Pratt <pratt@...> wrote:

>I have not been able to find a package/class for Java that contains a
>parser that can parse a 8601 date/time string.
>
>The Java SimpleDateFormat will allow you to specify a particular
>format - but not one that recognizes the various 8601 formats. e.g.
>parse  "2000-03-01T01:00:00", "2000-03-01", "20000
>301T01:00:00-09:00", etc. without basically doing a complete
>pre-parse.
>
>Anyone know of a Java class for this? I can't be the first person to
>run into this.

    In a search of the Google Internet search engine today, the closest
I was able to come -- at least in 10 minutes of searching -- are the
Java classes "hplb.misc.Time" and "hplb.util.Cal", described at:

    http://www-uk.hpl.hp.com/people/ak/java/doc/hplb.misc.Time.html
    http://www-uk.hpl.hp.com/people/ak/java/doc/hplb.util.Cal.html

    and which are cached, respectively, by Google at:

<URL:http://www.google.com/search?q=cache:www-uk.hpl.hp.com/people/ak/
java/doc/hplb.misc.Time.html>
<URL:http://www.google.com/search?q=cache:www-uk.hpl.hp.com/people/ak/
java/doc/hplb.util.Cal.html>

    These classes include methods for generating ISO 8601 date or
date/time strings from other time/date values.

    This does not solve Craig's problem of finding a Java class that
contains methods for parsing the various ISO 8601 date/time formats
in a text string.  Nonetheless, it's possible that the author of
these classes, Anders Kristensen, might have developed other parsing
routines, as well.

    (This UK-based site was unreachable today, so it was somewhat
awkward to view its pages via the Google cache, including the full
list of classes and interfaces on this site at
<URL:http://www.google.com/search?q=cache:http://www-uk.hpl.hp.com/peo
ple/ak/java/doc/tree.html>.)

    As an alternative, the "Date::Manip" module for Perl includes a
flexible parsing routine that handles a variety of ISO 8601 dates,
ParseDateString():

    http://www.engelschall.com/ar/perldoc/pages/module/Date::Manip.html

    If this routine comes with full Perl source, this might serve as
handy pseudo-code for someone developing Java methods to parse ISO
8601 strings.  (If the Perl source makes use of regular expressions,
then the equivalent regex capabilities would obviously need to be
present in the Java environment.  Unfortunately, I know very little
about Java ...)

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

Hi,

I'm very glad to see a steady increase in the number of members to
this group but am a bit perplexed as to why the discussion and
information flow seems to have dried up.  There is no doubt that the
ISO8601 message is trickling through onto many web sites. I have been
encouraging sites with ambiguous dates and times to 'see the light'
with mixed responses. Some embrace the idea and conform immediately,
others say it's a good idea but their bosses don't want to change
their pages and others just do nothing and don't even bother replying
to my suggestion. What sort of responses have any of you subscribers
had? Do you think the message is getting across?

Steve Adams

----- Original Message -----

From: Steve Adams

To: ISO8601@onelist.com

Sent: Thursday, March 23, 2000 06:24 AM

Subject: [ISO8601] ISO8601 interest

From: "Steve Adams" <steve@...>

Hi,

I'm very glad to see a steady increase in the number of members to
this group but am a bit perplexed as to why the discussion and
information flow seems to have dried up.  There is no doubt that the
ISO8601 message is trickling through onto many web sites. I have been
encouraging sites with ambiguous dates and times to 'see the light'
with mixed responses. Some embrace the idea and conform immediately,
others say it's a good idea but their bosses don't want to change
their pages and others just do nothing and don't even bother replying
to my suggestion. What sort of responses have any of you subscribers
had? Do you think the message is getting across?

Steve Adams

---

---

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

On 2000-Mar-23 Steve Adams wrote:


[2000-Mar-23]


> I'm very glad to see a steady increase in the number of members to
> this group but am a bit perplexed as to why the discussion and
> information flow seems to have dried up.

I have been away since late last month, so I have provided no input for many
weeks. However, my Inbox still gets people writing to me about various ISO
8601 issues on a regular basis, mostly after looking at my Web Site, or
occasionally from one of my magazine articles on the subject. My Web Site
passed the 3000 visitors mark the other day (in 15 months). I've had four
ISO related email messages in the last few days alone. I try to direct them
to other relevant Sites, and to this list.



> There is no doubt that the ISO8601 message is trickling through
> onto many web sites. I have been encouraging sites with ambiguous
> dates and times to 'see the light' with mixed responses. Some
> embrace the idea and conform immediately, others say it's a good
> idea but their bosses don't want to change their pages and others
> just do nothing and don't even bother replying to my suggestion.
> What sort of responses have any of you subscribers had? Do you
> think the message is getting across?

A mixed bag, much as you have had. Keep banging away, it WILL happen. I
can't get a resonse out of BT Cellnet or Genie at the moment. Can someone
else try.


Try this one for wierd dates:  <http://www.ggw.org/asras/snimages/>.

Dates are like '10/25.34/99'; which would be written as '1999-10-25.34' in a
format that we would understand (1999 October 25, and 0.34 of a day).
Astronomers often use decimal fractions of a day, in dates, as this is
easier to do than hours, minutes, and seconds in some calculations (I don't
have a problem with that). Astronomers always use the UTC time zone (also
known as 'Z'), which is great. If you find an astronomer using local time,
then beware! However trying to use decimal fractions of a day, combined with
the old US 'mm/yy/yy' (two-digit year, not even 2000-compliant) date format
really makes life confusing; and the sited noted above really is very
confusing to the average person. Anyone fancy writing to them?

As an astronomy site, they should already be aware that astronomers should
always use the Year-Month-Day format, and as the W3C (World Wide Web
Consortium) say that this format is the default of the Web, then I really
can't see why <http://www.ggw.org/asras/snimages/> should use a format like
'10/25.34/99'. It makes no sense whatsoever.

Perhaps Paul Hutchinson  <pmh@...>  would care to add this site to
his list of "Clear as Mud Dates Hall of Shame" Web Page which I last noted
as being at  <http://how.to/FormatDates/>. I haven't looked at this site for
a long time. Must pay a visit soon, to see how it is going. Or, perhaps he
could give an update via this ISO8601 mailing list, if he is still out there
in the audience?



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-03-23]

.end

On 2000-Mar-22 Nagi wrote(>):


[2000-Mar-23]



> I have been researching the web and your site to find out how two digit
> years are expanded to four. I would assume ISO has a standard for this but I
> had no luck finding it. In the end, I figured I might as well send an email
> to the "GURU" in the subject.

There is no standard for two digit year dates, other than that it is implied
that the user knows which 100 year band (1900-1999 / 2000-2099 / etc) his
data refers to. In most cases all dates are assumed to be in the current
band; ie everything should be prefixed '20' at the present time. I would
urge you to always use all four digits for the year in everything that you
do. You can download the full text of ISO 8601 from my FTP Site as a PDF
document. You need Acrobat Reader to read it. Follow the links from
<http://www.qsl.net/g1smd/>.



> There are three ways to do it:
> 1. two digit years 0-50 expand to 2000-2050 and 51-99 expand to 1951-1999.

This is a Windowing technique (Fixed Window) and will cause you problems if
you have Date of Birth information for any person aged over 50! In addition,
the Pivot date will need to be altered every 25 years or so, for ever more;
to keep pace with current date. You will also have to DELETE all old data
from the database, otherwise it will be corrupted.


> 2. two digit years 0-70 expand to 2000-2070 and 71-99 expand to 1971-1999.

Again, a Fixed Window; just with a different pivot date. Date Of Birth
information for anyone over age 30 will translate incorrectly at the present
time.


> 3. the expansion depends on the current year. It is a moving window
> with respect to current year, with current year being in the middle
> of the hundred years.

This has a danger; that data goes out of range of the window without the
user noticing, and therefore translates incorrectly by 100 years. Old data
has to be deleted out of the database EVERY YEAR. This may not be convenient!

In the IBM Year 2000 Book (GC28-1251-xx), Windowing Techniques are discussed
and stated to be only temporary solutions, and that conversion of all data
and programs to a four-digit year format is the only long-term solution to
use. The pivot date that you use in you conversion process relies on you
knowing what 19xx date is the earliest date to be found in your data. If you
have Date Of Birth Information back to 1920, then use 1919 as the Pivot. If
you have Information going back to 1900, then you already have a problem in
that you won't know if '00' refers to 1900 or 2000 (unless perhaps all
people in your database are aged over 16 perhaps, then this problem won't
occur until 2016).


> Which of the three is the ISO standard? Your response will be greately
> appreciated.

I hope that my answer is of some help, even if the choice that you face
isn't exactly clear. What data are you attempting to convert?


There is a discussion group about ISO 8601. If you want to join, then visit
<http://www.saqqara.demon.co.uk/>. It is a low volume list, but brings many
of the core 'activists' worldwide together, to share ideas.



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-03-23]

.end

On 2000-Mar-20 Richard wrote(>):


[2000-Mar-23]



> Thanks for your efforts on behalf of ISO 8601.  I was using a
> YYYY-MMDD-HHmm format for personal records about 50 years ago.

It's quite well known in some Military circles, and is the DEFAULT format
for all of the US military these days, as YYYY-MM-DD HH:MM:SS. Federal
Government also officially adopted it in the FIPS 4-1 standard back in 1968.
It has been used in Scandinavia and Eastern Europe for hundreds of years,
and in the Far East for several thousand.



> I got an e-message the other day referring to something that they
> said happened 11/03/00 e.s.t.  I asked them if they meant
> November 3, 1900, or 11:03:00 a.m., eastern standard time.

For the WEB, the ISO 8601 standard is the default as defined by W3C (World
Wide Web Consortium) <http://www.w3.org/>, the people who define the
technical standards that the WEB works to. For other things, like email and
USENET, there is still some catching up to do.



> While I generally support the Year-month-day format, I am opposed to the
> addition of insignificant leaddng zeroes for human consumption.

I would be worried by a date like 2000-1-1, I would worry that the month was
supposed to be 10, 11 or 12 not 1, or that the day was any of 10 to 19, 21,
or 31... that the sender had omitted a digit. Of course, you can't guard
against a user typing the wrong digit, but if the format is to always put
two digits for the month, and two for the day, then it is obvious when a
digit is MISSING. Having a fixed format, also means that dates in lists fall
neatly into columns, making them much easier to read.



> I have also used a month#-day#/year# format.  For example, my birth date of
> 1-10/29.  This of course follows the OLD American order rather than the
> British/Continental format.

And, that is where most of the problems are.... it isn't obvious if '1-10'
is referring to 1st October, or January 10th. And, 29, could be 1829, 1929,
2029 etc. Now that ANSI standards refer to the Year-Month-Day format, then
that is now the default for US users as well, companies like IBM have aleady
adopted it.



> For full dates I concluded that I would use, for example, 2000 Mar 20 Mon
> 3:25 becuse the day of the week rolls over every 7 days while the day of
> the month only rolls over every 28 to 31 days.

I agree. I use  '2000-Mar-20, Mon'  or  '2000 March 20, Monday'  and so on,
where necessary. It is possible to set this format in the Windows Control
Panel, under Regional Settings. In 'Short Format Date' use  'yyyy-MM-dd'. In
'Long Format Date' use  'yyyy MMM dd,  ddd'  or  'yyyy MMMM dd,  dddd'  to suit.



> As for Internet e-mail.  I have noted the following.  RFC 822, which set
> the standard for Iternet "mail" format refers to the military time zone
> designations A-I, K-Z.  I think that is inverted in RFC 822.  It says that
> N-Y refer to times 1 to 12 hours later than UT, and I believe they refer to
> times 1 to 12 hours earlier than UT.

RFC 822 is showing its age. There is a later update (to make 2000-compliant
and so on), but no general move to ISO formats yet. However, it will come in
time. I don't like the lettered Zones. I know that Z or Zulu is the
equivalent to UTC, and I then avoid the other designations, they aren't easy
to remember, or practical to use.



> They also allow time zones to be described by their offset from UT.  For
> example, the current time (eastern standard time) (military zone R) would
> be given as 03:30:48 -0500.  In my opinion they ought to abandon the offset
> and use the "onset" or correction necessary to convert local time to UT.
> That would mean the above time would be rendered as 3:30:40 +0500.  Which
> means my local time pluse 5 hours no minute yields UT of 8:30:40.

The numbered Zones are much clearer than using letters: '+0500' means a
place that is 5 hours ahead of UTC (eg Moscow), and '-0500' is 5 hours
behind UTC (eg New York). I know some people would prefer to use + for Zones
that are West of UT, but if you think about how a graph is shown, Positive
values go to the Right, and Negative values run to the left. If you now
think of a map of the world (with Greenwich meridian on the centre line),
then this is how the time Zones are shown on that map (+ve to the right, -ve
to the left). Incidentally this is also true for Latitude and Longitude. If
Signed Numbers are used, then +ve numbers are for North and East, and -ve
numbers are for South and West, just as on a graph again.



> My other gripe with Internet "mail" is that so many programs misuse the
> word "recipient" to refer to an addressee.  A message can be addressed to
> anyone or anything, real or imaginary.  A recipient must be a real agent
> (person, organization or program) that actually receives the message.  Even
> delivery does not guarantee receipt.  Without receipt there can be no
> recipient.

Post and hope applies! Mind you, it's much the same with posting an envelope
into the box, it's a lottery as to whether it gets there these days!

There is a discussion group about ISO 8601. If you want to join, then visit
<http://www.saqqara.demon.co.uk/>. It is a low volume list, but brings many
of the core 'activists' worldwide together, to share ideas.



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-03-23]

.end

[2000-Mar-25]


Two small typing errors appeared in my earlier message.
I had 100 emails to read and about 10 replies to do in a limited time.

The details are:



I wrote:

> [2000-Mar-23]

> Try this one for wierd dates:  <http://www.ggw.org/asras/snimages/>.

> Dates are like '10/25.34/99'; which would be written as '1999-10-25.34'
> in a format that we would understand (1999 October 25, and 0.34 of a
> day). Astronomers often use decimal fractions of a day, in dates, as
> this is easier to do than hours, minutes, and seconds in some
> calculations (I don't have a problem with that). Astronomers always use
> the UTC time zone (also known as 'Z'), which is great. If you find an
> astronomer using local time, then beware! However trying to use decimal
> fractions of a day, combined with the old US 'mm/yy/yy' (two-digit year,
> not even 2000-compliant) date format really makes life confusing; and
> the sited noted above really is very confusing to the average person.
> Anyone fancy writing to them?


Of course, 'mm/yy/yy' should read 'mm/dd/yy' in the paragraph above; however
they really ought to be using 'YYYY-MM-DD' as WE all know.

The Web page address  <http://www.ggw.org/asras/snimages/> is incomplete.
You need to go to this page, then follow links to some of the pages that
have the word 'sub page' in the link text. There you will find the crazy dates.



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-03-25]

.end

On 2000-Mar-24 Nagi wrote:


> Thank you Ian for the lengthy reply and some great insights and
> weblinks. The problem I am trying to solve is - the user is used
> to inputting 2 digit years in the application. Our database always
> stores 4 digit years. However, before I insert the data, I need to
> convert the user provided 2 digit year to a 4 digit year. This is
> where I am not sure how to set the ground rules. I hope that helps
> you understand the context of my question.



[2000-Mar-25]


Yes. This is a problem. You need to examine what data is going in, and set
the 100-year range accordingly. If the application involves (for example)
Date of Birth information, you need to see what age are all of the people
who are being stored. If it is always children, then set a pivot date of say
1970 or 1980, and you will not have to modify your program until 2070. If
you deal only with elderly people then you can just prefix all dates as
19xx, as you will not encounter a 60 year old person born after 1999, until
after 2059. People born in 18xx will already cause you problems, unless you
run the window from say 1890 (this allows a 110-year old person to exist in
your data) to 1989 (no-one under 11 can exist in your data this year, under
12 next year, and so on - when this figure reaches say, 50, you need to move
your pivot dates again).

This is a difficult problem, and will take a lot of time to resolve with
your client. Any Windowing solution will need constant review to ensure that
no-one tries to input data that could be wrongly interpreted by 100 years.
It would be easier in the long run, to convince your client that the use of
two-digit year date formats is extremely unwise. However, if they still
insist that a two-digit year date must be used for input, you must insist
that all dates are always immediately displayed and printed using all four
digits, so that wrong data can be easily spotted. For example, in 2006, a
user types 02/02/02 for a date of Birth of a person 104 years old, and the
dispay shows 2002 Feb 02, so alerting someone to the fact the computer
assumes that this person is only 4 years old.

The biggest problem is that you may need different Windows for different
data fields. For a mortgage database of standard 30 year terms for example,
you may require three fields: Date of Birth, Date Mortgage Started, and
Completion Date. There will be no-one aged less than 18 in your data, but
some people may be up to 70 or 80 years old. Current mortgages will have
been started sometime in the last 30 years, and more will be taken out in at
least the next 30 we will assume. Current mortgages will complete sometime
in the next 30 years. Mortgages taken out in 30 years time will complete in
60 years time. So your data could span 140 years (from oldest Date of Birth,
to final payment of a mortgage completing in 60 years time), and requires
different windows rules for different fields. Now you know why so many
people recommend using all four digits for the year, and adopting the ISO
8601 Year-Month-Day date format.

Perhaps you already know all these things, but I hope this helps. Plese see
if you can find the IBM Year 2000 Book on the WWW, this discusses Windowing
in more depth. I have a link to an old copy of this document on my Web Site.
The publication number is GC28-1251-xx (where xx is the version number from
01 to perhaps 07 or 08). You may also find it by following links from IBMs
main Web Site at  <http://www.ibm.com/>.

There are a number of great Web Pages about the ISO 8601 standard. Follow
the various links from my Web Site to pages written by Markus Kuhn, Steve
Adams, and others. These people are the real gurus! A short text at (or
linked from)  <http://how.to/FormatDates/>. is also useful. There are many
others: try your favourite Search Engine for more:
<http://www.savvysearch.com/> or whatever.

By the way. Which country are you in? I'm in England, UK, Europe. This isn't
obvious from my email address, or Web Page address either.


There is an email discussion group about ISO 8601. If you want to join, then
visit  <http://www.saqqara.demon.co.uk/>. It is a low volume list, but
brings many of the core 'activists' worldwide together, to share ideas.



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-03-25]

.end

In Taiwan, there is an ROC ordinal year system counting from 1912
as the 1st year of the Republic of China (ROC)(foundation). Now it is
89th ROC year. This system can be found on the websites in Taiwan and
is officially used there, but I, as a citizen from there, strongly
discourage its use because:

(1)It can conflict with 2-digit common-era (CE, the same as AD, but I
prefer CE) year, e.g. on the bottom of English page of Taiwanese
Legislative Yuan at http://www.ly.gov.tw/lyeng.htm
88/05/01 which could mean 88th ROC year (1999) or 1988. It cause 11-
year difference and is confusing. It requires wasteful conversion
back and forth (Gregorian calendar months & days are already in use
there).

(2)It is too political. Most nations no longer formally recognize the
ROC governing Taiwan. Instead, they now recognize the People's
Republic of China (PRC) as the only legitimate Chinese government and
Taiwan is part of China (which would mean the PRC, and the preword of
the PRC Constitution claims Taiwan). Therefore, it serve no good
purpose except to highlight how long the ROC has existed. Some
democratic activists oppose its use because foundation of the ROC in
1912 was an old history.

   Nowadays, even more and more Taiwanese use CE year alone without
even using ROC year in parenthesis, such as 2000 alone rather than
2000 (89th ROC year). I think the ROC year should be abandoned in
favor of CE year (some others have similar proposal as well). But
before the ROC year is officially abandoned, everyone visiting
Taiwanese websites would still face mix-up of CE & ROC years. The
best solution is to use 4-digit ISO-compliant CE year.

Sincerely,

Mr Yifan Ji

PS Caution: Some Chinese & Taiwanese websites show mm/dd/yyyy order
for dates. I do not understand why they do so. It is not only
confusing but also a non-sense there geographically.

In Taiwan, there is also a pre-ROC year system counting back from
1911 as the 1st year before the foundation of Republic of China (ROC)
(1st pre-ROC year). 1910 was 2nd pre-ROC year. 1909 was the 3rd pre-
ROC year, and so on. This is still used when describing history,
including years of birth of those who were born in 1911 or earlier.
Dr. Sun Yat-sen, founding father of the modern China, was born on
1866-11-12, which was also the 46th pre-ROC year.

   However, I, as a Chinese citizen from Taiwanese, oppose continued
use of both ROC year & pre-ROC year because:

(1)They add unnecessary conversion cumbersome. Taiwanese people
cannot avoid international common era year entirely whether for now
or history. For example, saying the Dutch people occupied Taiwan in
the 288th pre-ROC year rather than 1624 is not so meaningful.

(2)Again, it is too political, as I have said on 2000-04-05 in my
message "ROC year used in Taiwan".

   In fact, Taiwan was ceded to Japan in 1895 before the foundation of
Republic of China in 1912. Japan gave up Taiwan in 1945 after defeat
of World War II. When the Communist founded the People's Republic of
China on 1949-10-01, they abolished the ROC year in favor of common
era year. After 1949, many nationalist politicians retreated from
mainland China had brainwashed Taiwanese's minds by force. Imposing
ROC & pre-ROC years upon Taiwanese people is just for these
politicians to symbolize their belief (they wanted to fight back the
Communist after major defeat).

   The Nationalist Party, after ruling for more than 50 years,
recently failed Taiwanese presidential election on 2000-03-18, the
Democratic Progressive Party candidate Chen Shui-bian won. He will be
inaugurated on 2000-05-20. Perhaps the ROC year will be phased out
within his 4-year term (after that, he may try to run one more term
but not two), and I look forward to seeing that.

Sincerely,

Mr. Yifan Ji


--- In ISO8601@egroups.com, "Yifan Ji" <yfji@h...> wrote:
>   In Taiwan, there is an ROC ordinal year system counting from 1912
> as the 1st year of the Republic of China (ROC)(foundation). Now it
is
> 89th ROC year. This system can be found on the websites in Taiwan
and
> is officially used there, but I, as a citizen from there, strongly
> discourage its use because:
>
> (1)It can conflict with 2-digit common-era (CE, the same as AD, but
I
> prefer CE) year, e.g. on the bottom of English page of Taiwanese
> Legislative Yuan at http://www.ly.gov.tw/lyeng.htm
> 88/05/01 which could mean 88th ROC year (1999) or 1988. It cause 11-
> year difference and is confusing. It requires wasteful conversion
> back and forth (Gregorian calendar months & days are already in use
> there).
>
> (2)It is too political. Most nations no longer formally recognize
the
> ROC governing Taiwan. Instead, they now recognize the People's
> Republic of China (PRC) as the only legitimate Chinese government
and
> Taiwan is part of China (which would mean the PRC, and the preword
of
> the PRC Constitution claims Taiwan). Therefore, it serve no good
> purpose except to highlight how long the ROC has existed. Some
> democratic activists oppose its use because foundation of the ROC
in
> 1912 was an old history.
>
>   Nowadays, even more and more Taiwanese use CE year alone without
> even using ROC year in parenthesis, such as 2000 alone rather than
> 2000 (89th ROC year). I think the ROC year should be abandoned in
> favor of CE year (some others have similar proposal as well). But
> before the ROC year is officially abandoned, everyone visiting
> Taiwanese websites would still face mix-up of CE & ROC years. The
> best solution is to use 4-digit ISO-compliant CE year.
>
> Sincerely,
>
> Mr Yifan Ji
>
> PS Caution: Some Chinese & Taiwanese websites show mm/dd/yyyy order
> for dates. I do not understand why they do so. It is not only
> confusing but also a non-sense there geographically.

This is my first posting.  Hope I am not reposing this question.

I am trying to find the ISO 8601:1990 (or the latest 8601) to
download.

If you have a link to where ISO (or other local standard body) posting
it please forward it to me.

Any additional information is welcomed.

I have the ISO 8601:1988 from
http://www.iso.ch/markete/8601.pdf

and the draft for Version 3
ftp://ftp.qsl.net/pub/g1smd/8601v03.pdf

Thanks

Dear TA:

   I am glad to see you now say Last updated May 15, 2000 instead of 5/15/00.
But "Hits since 6/1/98" is not clear enough yet.

   ISO 8601 does not deal or replace with language-dependent dates.
Anyway, if m/d/y order is preferred, the month should be written in word in
lieu of number, especially on Internet.

Yifan Ji

>From: "INFO" <transalt@...>
>Reply-To: <transalt@...>
>To: "Yifan Ji" <yfji@...>
>Subject: RE: Potentially misleading dates
>Date: Mon, 22 May 2000 13:32:39 -0400
>MIME-Version: 1.0
>Received: from [198.67.15.2] by hotmail.com (3.2) with ESMTP id
>MHotMailBAF2B98600A7D82197E4C6430F02F9DD0; Mon May 22 10:29:43 2000
>Received: from cassie (transalt.domain1.echo.net [204.178.128.54])by
>echonyc.com (8.9.3/8.9.3) with SMTP id NAA12761for <yfji@...>; Mon,
>22 May 2000 13:29:38 -0400 (EDT)
>From transalt@... Mon May 22 10:34:17 2000
>Message-ID: <NDBBKKOFGKMLEJJPKFNHEEMPCBAA.transalt@...>
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
>In-Reply-To: <20000512064919.48442.qmail@...>
>
>Dear Yifan-
>Thanks for your input. We are aware that our date notations do not conform
>to international standards. However, the majority of our members are based
>in the New York Metropolitan Area, and are used to the American system of
>noting the date. As these are our members who are most likely to actually
>attend events listed on our calendar, we made a conscious decision to
>adhere
>to the American notation, so as to avoid confusion. We know that this
>engenders confusion for our international website viewers, however, it was
>a
>question of utility. Hopefully we will soon see the US formally switch to
>international notations sometime soon, so that we may follow suit.
>Again, thank you for your input.
>Sincerely,
>Catherine Fennell
>
>-----Original Message-----
>From: Yifan Ji [mailto:yfji@...]
>Sent: Friday, May 12, 2000 2:49 AM
>To: info@...
>Subject: Potentially misleading dates
>
>
>Dear Sir/Madam,
>
>I recently visited your website at http://www.transalt.org/ and noticed
>that you are using a confusing date notation.
>
>People from all over the world (don't forget foreign members) are able to
>visit your site and there are many date formats currently in use. These
>visitors might not obtain full value from the information you are providing
>if they are not sure of the date it represents.
>
>Did you know of the existence of an international date format defined
>by the International Standards Organisation as ISO 8601 "Data
>elements and interchange formats - Information interchange -
>Representation of dates and times".
>This defines the date in such a way to ensure there is no confusion as
>to which date is represented.
>
>For example, what date is 27/04/93? Most likely 27th April 1993.
>What date is 11/02/98?  It could be 11th February 1998 or 2nd November
>1998.
>When we move into the 21st century, it could become even more confusing.
>What about 09/12/18?  It could be 9th December 1918 or 2018, or 12th
>September 1918 or 2018.
>
>What about 2011-07-12? Due to the four number prefix this is instantly
>recognisable as the ISO8601 format so it MUST be the 12th of July 2011.
>No other possibility therefore no possible confusion.
>
>The basic format is CCYY-MM-DD where CC is the century, YY is the year
>in that century, MM is the month in  numeric format and DD is the day in
>numeric format.  Note that this has the largest time unit on the left
>and decreases in unit size as you move to the right.  If you see a four
>number prefix then it must be the century/year first and therefore an
>ISO8601 representation of the date.
>
>To take this further, adding the time in 24 hour format can give a
>representation of a point in time as a definition decreasing in unit
>size as you move left to right.  For example, 1998-12-25 12:23:30
>
>For further examples and some more convincing arguments to use this
>format please see http://www.saqqara.demon.co.uk/datefmt.htm or join
>the ISO8601 community at http://www.onelist.com/community/ISO8601 where
>many people from around the world are trying to standardise on this date
>format.
>
>If you have any questions about the International Date Format, please
>email me at yfji@....
>
>Thank you for taking the time to read this.
>
>Regards
>Mr. Yifan Ji
>
>
>________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

On 2000-May-23 Yifan Ji wrote(>>,>):


>> From: "INFO" <transalt@...>
>> To: "Yifan Ji" <yfji@...>
>> Subject: RE: Potentially misleading dates
>> Date: 2000 May 22, Mon, 13:32:39 -0400
>>
>> Dear Yifan-
>> Thanks for your input. We are aware that our date notations do not
>> conform to international standards. However, the majority of our
>> members are based in the New York Metropolitan Area, and are used
>> to the American system of noting the date. As these are our members
>> who are most likely to actually attend events listed on our calendar,
>> we made a conscious decision to adhere to the American notation, so
>> as to avoid confusion. We know that this engenders confusion for
>> our international website viewers, however, it was a question of
>> utility. Hopefully we will soon see the US formally switch to
>> international notations sometime soon, so that we may follow suit.
>> Again, thank you for your input.
>> Sincerely,
>> Catherine Fennell



>   I am glad to see you now say Last updated May 15, 2000 instead
> of 5/15/00. But "Hits since 6/1/98" is not clear enough yet.
>
>   ISO 8601 does not deal or replace with language-dependent dates.
> Anyway, if m/d/y order is preferred, the month should be written
> in word in lieu of number, especially on Internet.
>
> Yifan Ji




[2000-May-26]


Catherine Fennell hopes that 'we will soon see the US formally switch to
international notations sometime soon'. The really old news is that the US
has *already* officially adopted the ISO standard under ANSI X3.30 as well
as under the NIST FIPS 4-1 standard. It is now also the default date
standard of the US military, and used in long format as '2000-May-26' by
them. US companies like IBM have already adopted it, long ago, as part of
the fix for the Year 2000 Problem. It is also used on sites like
<http://ftpsearch.lycos.com/>. It already comes as the default standard of
the Internet as defined by both Internic and the World Wide Web Consortium
(W3C), though the old email standards have yet to be updated to reflect this.

As far as the old US notation of 'Month/Day' goes, the ISO format retains
this. The ISO format merely changes the Year from two digits to four digits,
whilst moving it from being the last item to being the first item. So,
'12/31/00' is rewritten as '2000-12-31'. It is much more difficult for
European people to make the change, as they have to flip the whole date end
to end: '31/12/00' changing to '2000-12-31' or '2000-Dec-31'. As Yifan Ji
hints, confusion will reign supreme the day after '01/01/01', as this is
written as '01/02/01' in some countries, as '02/01/01' in others, and
'01/01/02' in yet others. So what date is '03/05/02' for example? As the
Internet is very much an international medium, International Standards are
the way to go.

Astronomers all round the world have already used the equivalent of the ISO
format for well over 200 years, so the ideas used in ISO 8601 are certainly
not new. Now is the time to make the change....



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-05-26]

.end

[2000-Jun-02]



When I design and write Web Sites for other people, I always include a Hit
Counter from 'TheCounter.com' on the site. This free service offers an
in-page hit count display, and sends a weekly email with site statistics to
the registered Web Site owner.


The date format used in these email messages has been:

31 March
1 April
15 May  etc; not easy to read as it is not neatly arranged in columns.


About a month ago, the email format changed to:

2000-05-15
2000-05-16
2000-05-17  etc.


Initially there was a bug, where the first nine days of the month of May
printed in a format like:

2000-05-9  (rather than 2000-05-09)

so I'll check the first report in June to see if this glitch has been fixed.


Another success, and a site to recommend to others.



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-06-02]

.end

I took a look at the 'files' section at <URL:
http://www.egroups.com/files/ISO8601 > and found two versions of the ISO
8601 standard, one from 1988 and one from 1997 ('iso8601v03.pdf'). I
also have a later edition, 'iso8601v04.pdf' (don't remember where I got
it), but this isn't available in the 'files' section on Egroups.

Are the ones from 1997 and 1998 official editions or only working
drafts? The one from 1998 has an interesting chapter (5.6) on 'Recurring
time-intervals' ...

--
Karl Ove Hufthammer

[2000-Jun-17]



Please read  <http://www.qsl.net/g1smd/isoimp.htm>  and send me any
corrections, updates, or additional material that can be listed there.

Thank you.



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-06-17]

.end

Is it my imagination or are there more instances of people using '-'
rather than '/' as delimiters in non-ISO8601 dates, e.g. 06-29-00.
--
Pete Forman              | Disclaimer: This posting is originated by
Western Geophysical      | myself and does not represent the opinion
pete.forman@...  | of Baker Hughes or its divisions.

----- Original Message -----
From: "Pete Forman" <gsez020@...>
To: <ISO8601@egroups.com>
Sent: Thursday, June 29, 2000 4:30 PM
Subject: [ISO8601] Hyphens in non-ISO dates


| Is it my imagination or are there more instances of people using '-'
| rather than '/' as delimiters in non-ISO8601 dates, e.g. 06-29-00.

In my experience, it's your imagination! ;)

At least for US dates, '/' seems to be the most used delimiter, though lately,
I've seen a lot of web pages use '29-Jul-2000'. It isn't ISO 8601, but it's
unambiguous and very easy to read -- at least much better than 01/02/03 ...

--
Karl Ove Hufthammer

[2000-Jun-29]



This mailing list has been a bit quiet of late. How about each subscriber
out there posting a short message about what they have been doing recently
to advance the usage of ISO 8601. Give some details of the various people
and organisations that you have been contacting, and their responses. Let us
know about Web Sites that have already made the change to the new format.
Then tell us all about any other sites that have useful information about
the standard, or have good arguments for using it. Let us know about any
sites that have incorporated it into various official standards and
recommendations. We all know about the various national standards in many
different countries; I have a already compiled a list at:
<http://www.qsl.net/g1smd/isoimp.htm>. However, there are many other places
(perhaps some not so widely known?) that can be publicised. For example,
many years ago, the United Nations Economic Commission for Europe,
incorporated it into their Simpler Trade Working Agreements. This isn't too
widely known. In fact I had never heard of UNECE until I stumbled across
their web site at <http://www.unece.org/> some while ago.

What else can you all tell us about?



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-06-29]

.end

Folks,

My activities have focused on alerting Stratus VOS customers to the
ambiguity of 2-digit years starting January 2, 2001.  I'm concerned that
both customer employees and customer software will get confused beginning on
that date.  As I think I mentioned to this list some months ago, our
software (and, I expect, many other software packages) can handle both
leading-year and trailing-year formats when 2-digit years are used, as long
as the 2-digit year is not in the range 1-31.  For example, our software
lets you specify a date-string as:

06/30/00  or  00-06-30

because we know that 00 must be a year, and we map it to 2000 automatically.
We handle the European forms (day then month) by a user-settable parameter.

Things get interesting next January, because our software actually defaults
to YY-MM-DD, so the progression:

01/02/01
01/03/01
01/04/01

is actually the first day of February, March, and April, rather than the
2nd, 3rd, and 4th of January.  This is pretty nonobvious, at least to an
American. But it has been our documented behavior since 1982 and we can't
change it now.

We have spent a great deal of effort notifying our customers, of giving them
software to help detect problematic code, and encouraging them to test dates
in 2001 and beyond.  Several customers have reported problems in their code,
so we know that the issues are out there.  The solution is extremely simple:
always use full four-digit years.

If you want more details, read
ftp://ftp.stratus.com/pub/vos/doc/y2k/sray2k21.htm.

I have to say that I've been surprised that there has not been more mention
of this issue in the computer press or in the popular press.  It is
essentially a y2k issue all over again. (In fact, internally we call it the
"y2k+1" issue).

Thanks
PG
--
Paul Green, Senior Technical Consultant
Stratus Computer, 111 Powdermill Rd, Maynard, MA 01754
Voice: +1 (978) 461-7557; FAX: +1 (978) 461-3610
Speaking from Stratus not for Stratus

----- Original Message -----

From: Karl Ove Hufthammer

To: ISO8601@egroups.com

Sent: Thursday, June 29, 2000 11:22 AM

Subject: Re: [ISO8601] Hyphens in non-ISO dates

----- Original Message -----
From: "Pete Forman" <gsez020@...>
To: <ISO8601@egroups.com>
Sent: Thursday, June 29, 2000 4:30 PM
Subject: [ISO8601] Hyphens in non-ISO dates


| Is it my imagination or are there more instances of people using '-'
| rather than '/' as delimiters in non-ISO8601 dates, e.g. 06-29-00.

In my experience, it's your imagination! ;)

At least for US dates, '/' seems to be the most used delimiter, though lately,
I've seen a lot of web pages use '29-Jul-2000'. It isn't ISO 8601, but it's
unambiguous and very easy to read -- at least much better than 01/02/03 ...

--
Karl Ove Hufthammer

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

[2000-Jun-29]



This mailing list has been a bit quiet of late. How about each subscriber
out there posting a short message about what they have been doing recently
to advance the usage of ISO 8601. Give some details of the various people
and organisations that you have been contacting, and their responses. Let us
know about Web Sites that have already made the change to the new format.
Then tell us all about any other sites that have useful information about
the standard, or have good arguments for using it. Let us know about any
sites that have incorporated it into various official standards and
recommendations. We all know about the various national standards in many
different countries; I have a already compiled a list at:
<http://www.qsl.net/g1smd/isoimp.htm>. However, there are many other places
(perhaps some not so widely known?) that can be publicised. For example,
many years ago, the United Nations Economic Commission for Europe,
incorporated it into their Simpler Trade Working Agreements. This isn't too
widely known. In fact I had never heard of UNECE until I stumbled across
their web site at <http://www.unece.org/> some while ago.

What else can you all tell us about?



Cheers,

Ian.


<mail://g1smd@amsat.org>

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

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


[2000-06-29]

.end

In ISO 8601, the days of the week may be represented by numbers
from Monday as day 1 to Sunday as day 7. It is well-suit for Chinese
because Monday thru Saturday are said "xingqi" 1~6 and Sunday is
said "xingqiri". "Xingqi" alone means week. "Xingqi" 1~6 mean Mon-Sat.
   However, the United States Postal Service (USPS) uses a different
set numbers to represent the days of the week, from day 1 as Saturday
to day 7 as Friday, to form a payweek, for internal use, but not for
external use with the public.
   I, as an American postal clerk, favor ISO standards, but since
these 2 systems conflict, I use words in lieu of numbers for the days
of the week.
   The following table contrasts the differences of day numbers:

Monday    ISO #1 USPS #3
Tuesday   ISO #2 USPS #4
Wednesday ISO #3 USPS #5
Thursday  ISO #4 USPS #6
Friday    ISO #5 USPS #7
Saturday  ISO #6 USPS #1
Sunday    ISO #7 USPS #2

   In addition, ISO 8601 also specifies decimal fractions of times.
The USPS time clocks use decimal hours with 2 digits after decimal
points (.) in lieu of hours & minutes, e.g., 00:30=00.50,
04:00=04.00, 15:15=15.25, 23:45=23.75. Note the differences of colons
(:) and decimal points (.). 0.01 h = 0.6 min = 36 s.
   Because employees punching clocks at midnights generally punch ends
of work rather than begins, 24.00 rather than 00.00 is displayed.

Sincerely,

Justin Jih

Hi,

I am new to the list and I found this e-group from one of the
"date formats" pages.  Is there a list of all/some possible
date/time formats somewhere?

For example, I've seen the following formats:
1. M/D/YY (or M-D-YY) or M/D/YYYY (or M-D-YYYY), where M is between 1
and 12 and D is between 1 and 31.
2. MM/DD/YY (or MM-DD-YY) or MM/DD/YYYY (or MM-DD-YYYY), where MM is
between 01 and 12 and DD is between 01 and 31 (depending on the
month).
3. Mmm D YY (or Mmm D, YY) or Mmm D YYYY (or Mmm D, YYYY), where Mmm
is the 3-letter abbreviation for the name of the month and D is
between 1 and 31.
4. Mmm DD YY (or Mmm DD, YY) or Mmm DD YYYY (or Mmm DD, YYYY), where
Mmm is the 3-letter abbreviation for the name of the month and DD is
between 01 and 31.
5. Month D, YY or Month D, YYYY.
6. Month DD, YY or Month DD, YYYY.
7. D-M-YY or D-M-YYYY (or with hyphens replaced by slashes).
8. DD-MM-YY or DD-MM-YYYY (or with hyphens replaced by slashes).
9. DD-Mmm-YY or DD-Mmm-YYYY (or with hypens replaced by slashes).

10. H:MM(AM/PM), HH:MM
11. H:MM:SS(AM/PM), HH:MM:SS

Hmm, I guess I just have to go through all possible combinations...

Yikes!  :-)

Archie

----- Original Message -----
From: "Archie Medrano" <amedrano@...>
To: <ISO8601@egroups.com>
Sent: Wednesday, July 12, 2000 11:38 PM
Subject: [ISO8601] Request: List of All Possible Date/Time Formats (Nonstandard)


| I am new to the list and I found this e-group from one of the
| "date formats" pages.  Is there a list of all/some possible
| date/time formats somewhere?

You can find not all, but quite a few at <URL:
http://oss.software.ibm.com/developerworks/opensource/icu/localeexplorer/ >:

"The classes cover 45 different languages, further divided into 154 geographic
locales.  For each language, data such as days of the week, months, and their
abbreviations are defined."

--
Karl Ove Hufthammer

Strict subsets of ISO 8601 formats have been used as the basic data
types for representing dates and times in Extensible Markup Language
(XML) schemas.

    The W3C's document, "XML Schema Part 2: Datatypes", at
<URL:http://www.w3.org/TR/xmlschema-2/> notes that XML's date and
time formats "use lexical formats inspired by ISO 8601."

    Since the use of XML is growing remarkably rapidly, this could
potentially be the single most compelling way in which ISO 8601 date
and time formats will be introduced into new applications.

    It's surprising that there hasn't been more discussion about this
in this forum to date ...

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