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:[email protected]] 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 <[email protected]<mailto:[email protected]>> wrote: On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock <[email protected]<mailto:[email protected]>> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
