W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

RE: ACTION-129: Expressing timezones in the Calendar API

From: Andrew McMillan <andrew@morphoss.com>
Date: Fri, 26 Mar 2010 09:39:26 +1300
To: richard.tibbett@orange-ftgroup.com
Cc: pgladstone@cisco.com, public-device-apis@w3.org
Message-ID: <1269549566.21087.8829.camel@happy.home.mcmillan.net.nz>
On Thu, 2010-03-25 at 12:46 +0100, richard.tibbett@orange-ftgroup.com
wrote:
> 
> What we need is date and time information without any timezone
> implications associated with it - so we can apply any timezone value to
> any simple date/time object.
> 
> So I see 4 options:
> 
> 1. define a custom W3C 'Date' interface with no timezoned info (or Olson
> Timezone Identifiers only in this W3C Date interface). 
> 2. define a way remove (or set) the timezone on an ECMA Date object.
> 3. include wording in the spec to say that all timezone information
> derived on an ECMA Date in a TimezonedDate object must be ignored. (this
> is probably only going to confuse developers further and is likely not
> worth considering)
> 4. revert to the existing format used in the Calendar API spec for
> 'Date' objects e.g. 2010-03-25T11:24:19 - thereby removing dependence on
> the ECMA Date interface.
> 
> Any preferences on the above options? I would suggest option 1 is where
> we want to go (though we're getting in to ECMA standards territory and
> I'd personally prefer them to take up option 2 if possible).

Hi Richard,

It does sound rather like a rock and a hard place, and it's unfortunate
that the ECMA standard does not already have fully functional timezone
information.

I think it's worth at least raising the issue with the ECMA folk so that
they can start whatever process is needed to remedy their problems.

Beyond that, though, I would agree that (1) is very likely the best
option.


As an aside, there have been some discussions regarding changing the
timezone specification away from the Olson identifiers.  Olson himself
is retiring and the process of maintaining the data is will undoubtedly
change.  Since in some areas the names which Olson has historically used
for timezones are politically unacceptable it is likely that they will
be replaced with generic IDs in due course, and a translation process to
resolve names into the new IDs.

I don't think this should be an issue here, however - there will still
be identifiers of some kind - but it is worth bearing in mind, so people
are discouraged from validating them as having to be in some kind of
'Region/Location' form.


There are also plans afoot to provide standards for timezone database
services on the internet, to enable distribution of the information to
devices without needing software and/or operating system updates, which
have been increasingly problematic for timely delivery of updated
timezone information over the last few years.  From personal experience
when New Zealand changed the DST dates a few years ago it took well over
a year for updated timezone definitions to percolate through many
systems.


Cheers,
					Andrew.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
        Open Source: the difference between trust and antitrust
------------------------------------------------------------------------


Received on Thursday, 25 March 2010 20:40:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:07 GMT