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

[Stephen GOULD <sggould@oic.org>]

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@amsat.org 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
> 
> 
> 
> ------------------------ 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/ 
> 
>