Operating with arbitrary timezones

Alexander Jones alex at weej.com
Fri Aug 5 21:58:22 UTC 2016


What I meant by Date+Time components was actually { year, month, day,
hours, minutes, seconds, offset }. I think it makes sense to formalise this
as an expression of a time point (aka Date) *in a particular timezone*. For
example this can be used to decide e.g. "are these two time points in the
same month in this specific timezone", where that month may be e.g. 31 days
+ 1 hour. It could also be formatted for display.

Conflating Date projections into a timezone, with formatting, is a bit of a
conceptual error IMO. Convenient, but incorrect, as per Single
Responsibility Principle.

Alex

On Friday, 5 August 2016, Kris Siegel <krissiegel at gmail.com> wrote:

>  Once you endow them with a timezone offset they cease to represent
>> points in time, but rather more points in space, which adds complexity and
>> liability to any code handling Date objects
>
>
> I would disagree. Time isn't useful without a point in space (space and
> time should be looked at as one thing, not two) and since the Date object
> tracks it internally as UTC it has a *default* space.
>
> It's unfortunate that the boat has sailed on Date, because it's actually a
>> very inappropriate name for what it is. But what I think is really needed
>> is another distinct class for Date+Time components.
>
>
> Completely agree. Other than adding functions nothing can really change
> with the existing Date object. However this could be a real start to a new
> set of standard libraries for JavaScript that require the usage of import
> (so like Python, C++, C#, etc ECMAScript could have a set of libraries that
> can be included in the exact same fashion as including external libraries).
>
> I'm not really sure about not having arithmetic on this hypothetical new
> set of components (arithmetic is one of the most useful things about date
> time libraries) but that's details to be explored later and I guess this is
> getting off track from the original proposal here.
>
> On Fri, Aug 5, 2016 at 1:01 PM, Alexander Jones <alex at weej.com
> <javascript:_e(%7B%7D,'cvml','alex at weej.com');>> wrote:
>
>> I would object to your suggestion on the grounds that, as they stand,
>> Date objects represent exact points in time, with no ambiguities, and in
>> many cases that's exactly what you need. Once you endow them with a
>> timezone offset they cease to represent points in time, but rather
>> more points in space, which adds complexity and liability to any code
>> handling Date objects - similar to how any code expecting integral Numbers
>> has to be prepared for non-integral input.
>>
>> It's unfortunate that the boat has sailed on Date, because it's actually
>> a very inappropriate name for what it is. But what I think is really needed
>> is another distinct class for Date+Time components. You would project a
>> Date to its components (incl a tz offset, to avoid ambiguity around DST
>> shifts) for a given timezone, and with those components, answer the kinds
>> of questions you have. No arithmetic should be possible with such a
>> class, short of extracting a Date back from it and working on that.
>>
>> On Friday, 5 August 2016, Jordan Harband <ljharb at gmail.com
>> <javascript:_e(%7B%7D,'cvml','ljharb at gmail.com');>> wrote:
>>
>>> This message was in my Gmail spam folder due to "It has a from address
>>> in yahoo-inc.com but has failed yahoo-inc.com's required tests for
>>> authentication." - so it's possible nobody saw it.
>>>
>>> Replying all to bump.
>>>
>>> On Fri, Jul 29, 2016 at 12:51 PM, Juan Dopazo <jdopazo at yahoo-inc.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I’ve been working on Yahoo Mail and we’ve been running into multiple
>>>> issues with timezones. Currently EcmaScript supports only creating Date
>>>> objects with the User Agent’s timezone. However, we need to be able to
>>>> operate with whatever timezone our users selected in their settings page.
>>>> In most cases we just need to render dates with the correct timezone and
>>>> this is currently available using the Ecma 402 APIs. However, in other
>>>> cases we need to make certain computations taking into account an arbitrary
>>>> timezone and this is not covered by either EcmaScript or Ecma 402.
>>>>
>>>> In particular, we need to answer the following questions:
>>>>
>>>>    - Is a certain date in the current day/month/year? This means given
>>>>    a Date object, is it in the current day for an arbitrary timezone?
>>>>    - When is the start of the day/month for this timezone?
>>>>
>>>> Currently the only way to answer these questions is by calculating the
>>>> timezone offset for the timezone around the date we’re studying. And the
>>>> way to do that is to render a date using Intl.DateTimeFormat and recreate a
>>>> date object: https://gist.github.com/juando
>>>> pazo/b52820e368739ed19cb206e3f3893166.
>>>>
>>>> Ideally, EcmaScript would allow developers to operate on a Date object
>>>> for an arbitrary timezone. Would date.setTimezone(/* IANA string identifier
>>>> */) work? I know it’s a problem that is in the middle between EcmaScript
>>>> and Ecma 402.
>>>>
>>>> Thank you,
>>>>
>>>> Juan Dopazo
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> <javascript:_e(%7B%7D,'cvml','es-discuss at mozilla.org');>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160805/de81accc/attachment.html>


More information about the es-discuss mailing list