[ebxml-dev] Re: [ISO8601] Re: New Date Formats.

[Stephen GOULD <sggould@oic.org>]

Issue is Communications Time & Resource Cost not storage

I suggest the issue with dates in E-commerce applications is not disk storage 
but communication time and costs.

As Ed said ISO 8601 was initially proposed as a data interchange standard - see 
below message.

If you have been keeping track with what is happening with Space exploration ref 
"E-mail the final frontier" the real issue is to minimise communications time and 
resource costs
http://www.oic.org/V/uveaeca1.gif

Ian has pointed out in his e-mail on 14 Jan 2001 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.

Hence the proposal for a uniform coded date structure based on ISO 8601 format.

As most Data Interchange applications have 3 or 4 date fields eg date of invoice, 
date of delivery, date of order, date of payment due, date of early payment 
discount etc uniform date codes, particularly for international trade, are vital
hence the work carried out by OIC members to provide a uniform date calendar 
based on ISO 8601 for Data Interchange applications
http://www.oic.org/cpt/CPTAEDM1.htm

It is not designed for genealogy applications but for E-business applications 
which was the purpose behind ISO 8601

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

regards  
Stephen GOULD

On 26 Feb 02, at 0:45, Ed Davies wrote:

> bam wrote:
> 
> > ...  Unfortunately, ISO 8601
> > is far from compact, partly due to leading zeroes in
> > two fields and also due to required punctuation.
> 
> Can't argue that ISO 8601 often requires leading zeros but
> the punctuation is not required.  It defines two formats:
> "basic" which normally has no punctuation (except in some
> less common cases where punctuation is required to avoid
> ambiguity) and "extended" which does have punctuation.  I
> guess the idea is that the choice between the two should
> be made on a trade off between compactness and human
> readability.
> 
>   Basic:    20020225
>   Extended: 2002-02-25
> 
> Frankly I wonder if compactness has much benefit these
> days.  You'd need to store an awful lot of dates for
> two extra characters for each to take much of a bite out
> of a 40GB disk.  Putting a sensible standard compression
> scheme into MIME seems more useful than discussing whether
> or not dates should contain a few dash characters.
> 
> > (Futhermore, pre-emption of the dash makes that character
> > unusable in its customary role as an indicator for ranges
> > of values -- but that's an issue for another day. ;^>
> 
> ISO 8601 uses '/' for ranges of values.  Both '/' and '-'
> are commonly used for both date punctuation and for
> indicating ranges though '/' is somewhat more common in
> many national date notations, so perhaps use of '-' is
> an advantage for a "new" date format, giving extra distinction 
> to avoid confusion between old and new.
> 
> > ....
> > P.S.  In all of these schemes, there is also a
> > range problem, which I don't know how to address.
> > While I'm not too worried about Y10K, which may
> > invalidate ISO 8601 after 9999-12-31, I am unsure
> > how (or whether) ISO 8601 refers to the date of
> > Aristotle's birth (much less, the date of the
> > Permian extinction)
> > ...
> 
> ISO 8601 starts:
> 
> > 1. Scope
> >
> > This International Standard specifies the representation of
> > dates in the Gregorian calendar and times...
> 
> It says later (para 4.3.2.1):
> 
> > The use of this calendar for dates preceding the introduction
> > of the Gregorian calendar (i.e. before 1582) should only be 
> > done by agreement of the partners in information interchange.
> 
> Para 4.7 says:
> 
> > By mutual agreement of the partners in information interchange
> > it is permitted to expand the component identifying the calendar
> > year, which is otherwise limited to at most four digits.
> > .....
> > When expanded representations are used, provisions should be
> > made to prevent confusion of the expanded representations, with
> > other date and time representations used by the application.
> 
> It says the expansion should be in the form of a sign and(/or?)
> one or more extra digits in the year.
> 
> I think they've taken a fairly realistic view of producing a 
> workable notation for most applications - leaving the more unusual 
> cases to extensions to be defined in the context.
> 
> Remember, ISO 8601 is intended primarily for data interchange -
> not for applications intended purely for human consumption. 
> 
> However, extending its use into this area is a good idea for
> a number of reasons: a) to avoid international component order
> ambiguities, b) to get people used to the format so when they
> come across it in cases where it is intended both for machine
> and human use they are not too surprised, c) to easily allow
> stuff which was originally intended only for human use to be
> understood by machines (e.g., web search engines parsing text
> documents) d) to allow easy sorting, etc.
> 
> Adding "BC" or whatever stops a date being strictly in ISO 8601
> format but most of the above arguments for following the standard
> layout still apply to at least some extent.
> 
> A chap went into a museum and asked the age of a dinosaur.  The 
> keeper told him seventy five million and three years old.  "Oh", 
> he replied "I didn't realise they could be dated so accurately".  
> "Well", said the keeper, "when I joined it was seventy five 
> million years old and I've worked here three years now".
> 
> Do you want to represent the date of the Permian extinction 
> using year, month and day of month, or year, week and day of
> week?  I suppose it was global enough that the time zone was
> not too important, particularly as days were quite a bit 
> shorter then, I think.  They'd have had to apply lots of 
> negative leap seconds every day.
> 
> Ed.
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor ---------------------~-->
> Tiny Wireless Camera under $80!
> Order Now! FREE VCR Commander!
> Click Here - Only 1 Day Left!
> http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/zCsqlB/TM
> ---------------------------------------------------------------------~->
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
>