Operating with arbitrary timezones

[Alexander Jones]

I'm not sure I properly conveyed myself above given what you're saying. Let
me back up and explain more clearly now I have an actual keyboard in front
of me.

Currently we have `Date.prototype.toLocaleString()`, which conflates two
concerns:

1. Taking an unambiguous *time point* to a { year, month, day, hours,
minutes, seconds, milliseconds, timezoneOffset } for the selected
*timezone* (which is the subject of this thread).
2. Formatting those "local datetime components" in a way appropriate to a
specific locale.

Example:

```
d.toLocaleString("en-GB", {timeZone: "Europe/London"})
"06/08/2016, 09:02:13"
d.toLocaleString("en-US", {timeZone: "America/New_York"})
"8/6/2016, 4:02:13 AM"
```

What I'm suggesting is that these two concerns could be better separated.
Hypothetically, think of a new class with the awful and purely illustrative
name `LocalDatetimeComponents`:

```
const now = new Date();

const ldc = now.toLocalDatetimeComponents({timeZone: "Europe/London"});

assert(ldc instanceof LocalDatetimeComponents);

assert(ldc.month === AUGUST);

assert(ldc.timeZoneOffset === -1 * 60);
// UTC+1 for this specific time point, UTC+0 in winter

assert(ldc.timeZoneName === "BST");
// or GMT in winter

assert(ldc.toLocaleString("en-GB", {timeZoneName: "short"}) ===
"06/08/2016, 09:02:13 BST");
```

Note that the vast majority of the many possible `LocalDatetimeComponents`
values would not normally constitute real datetimes. But one benefit of
this separation is that it can express and format things like the time
2015-06-30T23:59:60.123Z (an actual time point within the most recent "leap
second") in spite of the fact that Date itself has no possible
representation of it. Perhaps some class or function other than `Date` can
produce `LocalDatetimeComponents` objects, maybe one that supports leap
seconds in applications that actually need it.

Alex

On 6 August 2016 at 00:08, Jon Zeppieri <zeppieri at gmail.com> wrote:

>
>
> On Fri, Aug 5, 2016 at 6:32 PM, Jon Zeppieri <zeppieri at gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 5, 2016 at 6:21 PM, Alexander Jones <alex at weej.com> wrote:
>>
>>> Don't confuse timezones with timezone offsets. They are different
>>> concepts.
>>
>>
>>
>> How am I confusing them? You wrote:
>>
>> 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.
>>
>>
>> And I'm saying, in response, that if you want to formalize the concept of
>> a time point in a particular time zone, this isn't a good way to do it. If
>> instead you want to formalize the concept of a particular point in time at
>> a particular UTC offset, then it's fine, of course, but at that point, I'd
>> just reiterate Tab's response.
>>
>> - Jon
>>
>
>
> Actually, let me try to clarify this a bit more. It sounds like you do not
> want a DateTime type to contain (what I would call) a robust concept of a
> time zone, because you think that date "projections" (by which I think
> you're referring to the kind of date arithmetic that I mentioned in an
> earlier post) are a separate concern.
>
> (I'm fine with that, by the way. Off the top of my head, I can't think of
> any date/time libraries that use a time zone as a separate input to date
> arithmetic functions, but it's a reasonable design.)
>
> However, you say that it would be useful to have the offset as part of a
> DateTime object, so that you could answer questions like: "Are these two
> points in time in the same month in this specific time zone?" Well, first
> question: which specific time zone (offset, actually, since that's what you
> want in the objects, right)? We're talking about either a two argument
> predicate function or a binary method, I assume. You might say that it
> doesn't matter which offset you use -- coerce in either direction you want;
> they're either in the same month or not. True (under certain assumptions,
> which I'll get back to in a moment) -- but if you're not interested in
> which month (and which offset), then you don't need the offset in the
> representation at all, because if you could coerce both to UTC to answer
> the question, then... well, you could just represent them in UTC.
>
> And all of this assumes that the question is a meaningful one to start
> with. I'll happily elide the question of what calendar we're talking about,
> but assuming we only care about the proleptic Gregorian calendar: when
> would you ever be interested in whether two points in time fall within the
> same month at a given UTC offset -- as opposed to a more robust notion of
> time zone? I might, at some point, care if two points in time are in the
> same month in America/New_York, but I can't imagine why I'd ever care if
> they are thus in UTC-5:00 -- precisely because UTC-5:00 doesn't really
> designate an area that uses the calendar in such-and-such a way, while
> America/New_York does.
>
> I suppose this is my long-winded way of saying that the very projections
> that you'd (understandably) like to avoid are implicit in almost any time
> zone-related question you'd want to ask.
>
> - Jon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160806/768a1dc3/attachment.html>