Re: ISO 8601 anyone?? - Or just who is this Gregory guy,and why is there a calendar named after him?

[g1smd@freeuk.com (Ian Galpin)]

On 2001-Apr-19 William J. Kammerer <wkammerer@foresightcorp.com> wrote in
<ebXML-core>:


[2001-Apr-20]



> Brian Hayes' problem that he's trying to solve by breaking apart date
> components involves "... date-time values that have implied values.
> For example, we might write on a paper document 'April 2001' with
> some implied notion of end-of-month or begining-of-month. Or, what
> is the standard for encoding a date time for a contract ending on
> April 30, 2001?"
>
> ISO 8601 provides the complete basic calendar month format CCYY-MM, so
> 2001-04 would be used for April 2001.  Was Brian sending out that huge
> copy of ISO 8601 so someone else could look it up for him? In the W3C
> Schema you could use the gYearMonth datatype, which "represents a
> specific gregorian month in a specific gregorian year," and has the ISO
> 8601 lexical form of CCYY-MM.


These are useful formats that could be used, but I prefer to state the
begining or end of the month, or year, with the full actual date.



> Finally, Ian Galpin "[notices] that all discussions of date here have
> always assumed usage of the Gregorian Calendar without question. Are
> there other people on the other side of the world devising systems based
> on one of the many other calendar systems still in common usage? If so,
> there are problems looming..."

> It's a conspiracy.


Not at all! I always try to take a global view of the way that things are
done. Often someone else, somewhere else may have a better idea or way of
doing something. About 75% of the world's population is not 'Western'. If
they decide to do things differently, then force of numbers means your
scheme loses: ASCII is being replaced by 'Unicode', 'UTF' and 'ISO10646' for
similar reasons. It's nice to be aware of any other possible ways of doing
things, just in case something useful can be aquired from them.

Astronomers are using a system called the Julian Day Number which counts the
days since BC 4713-Jan-01. So 2001-04-20T20:50:00Z maps to JD2452020.36806
for example. It'll never catch on in Trade, but it's a damn good system. I
will admit that widespread usage (over here) of the Chinese, or Hebrew
calendar is unlikely, but it's nice to know what other alternatives may be
out there.



> I've attached some background on the Gregorian
> Calendar from an old e-mail posted to EDI-L. Sometimes the Gregorian
> calendar is said to measure years of what's politely called the "Common"
> era.  Have people already forgotten that this Gregory guy was the pope?
> The calendar is now so ubiquitous that we sometimes overlook how
> culturally laden it is, marking the years since the Christ event, when -
> in orthodox Christology - the Word became flesh.  I predicted that
> someone would object to this cultural centrism as long ago as July 2000;
> see http://lists.ebxml.org/archives/ebxml-core/200007/msg00002.html.
> Congratulations, Ian.


There is loads of other stuff on Calendar issues. Anyone who thinks that
Date and Time is a 'simple' matter should read the following for homework!
  <http://www.tondering.dk/claus/calendar.html>
  <http://serendipity.magnet.ch/hermetic/cal_stud.htm>
  <http://serendipity.magnet.ch/hermetic/cal_stud/jdn.htm>
  <http://aa.usno.navy.mil/data/docs/JulianDate.html>
  <http://cossc.gsfc.nasa.gov/cgi-bin/cossc/datecnv.pl>
I have lost the other references that I was going to include here.



> Date: 1998-Jul-08 [Wed] 14:06:13  -0400
> From:  wkammerer@foresight-edi.com (William J. Kammerer)
> Subject: Re: Y2K - Doom and Gloom OR Y2K: Why Not?

> On MVS mainframes, I always preferred the SAS programming system
> (http://www.sas.com/), so I'm used to keeping my dates as an integer
> number of days since Jan 1, 1960. The formatting routines, further, were
> good for dates from Jan 1, 1582 till 20,000A.D. (Dates before 1960 were
> represented as negative numbers).  The 1582 date is not really a magic
> number, but rather the date Pope Gregory XIII took 10 days out of the
> Christian calendar to correct a build up of days (which accounts for the
> rule that every century year - except those divisible by 400, like
> 2000A.D. - is not considered a leap year).  Since Queen Elizabeth didn't
> like Catholics much, England didn't adopt this new Papist custom much
> later till 1752. Thus, providing date functions (like formatting and
> difference calculation) to span the time before the Gregorian calendar
> would probably have been a waste of time for SAS.


In the Julian Calendar every fourth year was a leap year. Under the later
Gregorian Calendar, every fourth year is a leap year, except that years
divisible exactly by 100 are not leap years, except again, that years
exactly divisible by 400 are leap years. So 1600, and 2000 were leap years,
but 1800, 1900, and 2100 are not. This has always been a big problem to
programmers, and many have got it wrong over the years. The definition for
leap year calculation is enclosed in the ISO 8601 standard. Yet another
useful thing that it has!



> I also like dates which naturally extended the YY parts (of YYMMDD or
> YYDDD formats) by treating the YY portion as the number of years since
> 1900A.D. Thus, the dates used internally in IBM's MVS (such as SMF and
> RMF records) were extended to YYYYDDD long ago, where YYYY as 0100
> simply means 100 years since 1900, or 2000A.D.


Many people have treated that behaviour as a 'bug', and in some systems the
year after '99' was '100', and that three-digit year has caused some
unexpected results.



> A similar technique has always been used to represent readable dates in
> FORESIGHT's SEF files, for example: 06/04/96:10:59:48 looks like it is
> non-Y2k compliant, but in 2000A.D., the date-time stamps will appear
> something like 06/04/100:10:59:48, where the 100 is number of years
> since 1900.  Internally, all of our date-time values have been kept as
> the number of seconds elapsed since midnight (00:00:00), January 1, 1970
> (the standard DOS/ Windows/UNIX  time_t).  This runs out of room in
> 2038, I think, but I'll be retired and gone.


There are loads of date rollover problems to come in the next few years, and
decades. The Year 2000 Problem was just one of many similar problems,
ticking away. The web site at:  <http://www.merlyn.demon.co.uk/> has some
interesting stuff on various 'Critical Dates'.



Cheers,

Ian.


<g1smd@freeuk.com>


[2001-04-20]

.end