Operating with arbitrary timezones

[Kris Siegel]

>
>  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> 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> 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
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160805/17bd7d09/attachment.html>