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]> wrote:
> On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock <[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
