The internationalization ad-hoc of TC 39 has already decided that edition 2 of the ECMAScript Internationalization API will support IANA time zone names in DateTimeFormat. Implementations will need to include best available information on all time zones or use equivalent operating system APIs.
I agree with Rich and Addison that adding a time zone to Date instances would only create confusion. I think the best way to add general support for time zones that's not tied to formatting would be methods that convert between incremental time (a Date instance) and field-based time. Under the covers, the Internationalization API spec already includes one direction as an abstract operation: http://www.ecma-international.org/ecma-402/1.0/index.html#ToLocalTime Note that this operation also takes a calendar - this hasn't come up on this thread yet, but is required because day/month/year values are always relative to a calendar. Jon, Andrew: would a method similar to that operation address your needs? Norbert On Feb 20, 2013, at 12:52 , Phillips, Addison wrote: > I agree that the tzinfo database and its identifiers should form the basis > for ES time zone support. There are some issues with providing support, such > as that it means that implementers will need to update several times a year > (as time zone rules change). > > Setting TimeZone on a Date object might not be the best design, even though > that’s sort of the design of Date today. Date values internally are actually > timestamps, “incremental time” [1] values---the number of millis since the > epoch date in UTC. Making the time zone a property of the date would be > confusing, since two incremental times are inherently comparable without > reference to LTO (local time offset) or time zone rules. > > The problem is that many of the methods of Date expose “field values” within > the date—what is the day number or what is the hour number? Where TimeZones > need to be used is when transforming dates to/from display. This should apply > to the new Intl DateFormat stuff. Maybe adding methods that take a time zone > or adding a time zone class might be better? There is the problem that Date > today has separate methods that return the local value and the “GMT” value. > > Addison > > Addison Phillips > Globalization Architect (Lab126) > Chair (W3C I18N WG) > > Internationalization is not a feature. > It is an architecture. > > [1] http://www.w3.org/TR/timezone/#incrementaltime > > From: Jonathan Adams [mailto:pointless...@me.com] > Sent: Wednesday, February 20, 2013 8:03 AM > To: Andrew Paprocki > Cc: es-discuss > Subject: Re: Override LocalTZA > > Excellent points and ideas here. > > I do think it would be extremely valuable to enable the ability to override > any Date instance and don't think this is harmful. > > Not sure how reasonable/unreasonable requiring tzdb for vendors but seems > worth it. Dates are important. Exposing something like > > Date.setLocalTimezone('America/Los_Angeles') > Date.getLocalTimezone() > > and leaving existing Date APIs untouched as well as preventing the guaranteed > problems of the natural inclination to pass static offsets seems perfect. > > -Jon- > > On Feb 20, 2013, at 7:03, Andrew Paprocki <and...@ishiboo.com> wrote: > > On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> > wrote: > What would be the best way to expose the localTZA for you purposes? > > Exposing localTZA at all would only lead to problems, IMO. > > class CST extends Date { > get localTZA() {return -6*60*60*1000} > } > > Timezones can not be referred to as static offsets. The only error-free way > to deal with timezones is to store the string (e.g. "Asia/Tokyo") and use > tzdb when performing conversion into another timezone (in this case, most > likely into UTC). UTC offset is a linear function that needs the full > datetime as input. Any other representation of it immediately introduces bugs. > > program. What is the localTZA of those preexisting date instances. Was it > fixed when they were created or is the default localTZA potentially > dynamically updated. What would an application want to happen? > > Precisely why you need to either store a fixed offset (fixed point in time -- > and realize that is what you're doing) or you need to store the full timezone > string (in the case of recurring events). Recurring events could not be > hacked up with a localTZA modification. If a recurring meeting occurs at 4pm > every day in NY, "America/New_York" will needed to be used to compute that in > other timezones to avoid errors. Also, you don't even need to get on a plane > and fly. For example, if you live in the Middle East, you are in the middle > of a work day when the US EST/EDT shifts happen. If you're referring to NY > datetimes and using a fixed or precomputed offset instead of treating the > conversion as a linear function, there will be errors. > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
