Operating with arbitrary timezones

[Jon Zeppieri]

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/20160805/082630d8/attachment.html>