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

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
------------------------------------------------------------------------