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

On Thurs, 25 Mar 2010 at 20:39, Andrew McMillan wrote:
> 
> 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).
> 
> 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.

I agree, though I don't have any formal liason with ECMA. Can another
member of our group (or the group itself) ask for feedback on option 2
from ECMA??

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

I've been thinking about this considerably today...perhaps I should
mention that I think I've looked at this from pretty much every angle
out there over the last few hours.

Sometimes the simplest solutions are the hardest to see but after a lot
of iterations (and a great deal of Javascript coding) I re-factored a
new proposal to the following:

WebIDL:
-------

[NoInterfaceObject]
interface TimezonedDate {
    attribute int year;
    attribute int month;
    attribute int day;
    attribute int? hours;
    attribute int? minutes;
    attribute int? seconds;

    attribute DOMString? tz;
};


Usage:
------

// Floating TimezonedDate Object:
{
	day: 26,
	month: 3,
	year: 2010,
	hours: 16,
	minutes: 58,
	// missing 'seconds' default to zero
	// missing or null 'tz' indicates that this object is not
timezone-bound
}

// Timezone-bound TimezonedDate Object:
{
	day: 26,
	month: 3,
	year: 2010,
	hours: 16,
	// missing 'minutes' default to zero
	seconds: 30,
	tz: 'America/New_York'
}


This object satisfies the three original requirements in [1].

The proposal here is to only store and communicate the properties that
are required to reconstruct a date and time object on any given platform
without getting in to the gritty details of timezone reconstruction
ourselves in the spec. We also side-step the issues with the ECMA Date
object (though the parameters provided can be used by a developer to
construct an ECMA Date object if desired). 

So what do we think...can we live with this?

- Richard


[1]
http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0203.html


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

Received on Friday, 26 March 2010 17:26:27 UTC