<div dir="ltr"><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Currently we have `Date.prototype.toLocaleString()`, which conflates two concerns:<br><br>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).</div><div class="gmail_extra">2. Formatting those "local datetime components" in a way appropriate to a specific locale.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Example:</div><div class="gmail_extra"><br></div><div class="gmail_extra">```</div><div class="gmail_extra"><div class="gmail_extra">d.toLocaleString("en-GB", {timeZone: "Europe/London"})</div><div class="gmail_extra">"06/08/2016, 09:02:13"</div><div class="gmail_extra">d.toLocaleString("en-US", {timeZone: "America/New_York"})</div><div class="gmail_extra">"8/6/2016, 4:02:13 AM"</div><div class="gmail_extra">```</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">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`:</div><div class="gmail_extra"><br></div><div class="gmail_extra">```</div><div class="gmail_extra">const now = new Date();</div><div class="gmail_extra"><br></div><div class="gmail_extra">const ldc = now.toLocalDatetimeComponents({timeZone: "Europe/London"});</div><div class="gmail_extra"><br></div><div class="gmail_extra">assert(ldc instanceof LocalDatetimeComponents);</div><div class="gmail_extra"><br></div><div class="gmail_extra">assert(ldc.month === AUGUST);</div><div class="gmail_extra"><br></div><div class="gmail_extra">assert(ldc.timeZoneOffset === -1 * 60);</div><div class="gmail_extra">// UTC+1 for this specific time point, UTC+0 in winter</div><div class="gmail_extra"><br></div><div class="gmail_extra">assert(ldc.timeZoneName === "BST"); </div><div class="gmail_extra">// or GMT in winter</div><div class="gmail_extra"><br></div><div class="gmail_extra">assert(ldc.toLocaleString("en-GB", {timeZoneName: "short"}) === "06/08/2016, 09:02:13 BST");</div><div class="gmail_extra">```</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Alex</div><div class="gmail_extra"><br><div class="gmail_quote">On 6 August 2016 at 00:08, Jon Zeppieri <span dir="ltr"><<a href="mailto:zeppieri@gmail.com" target="_blank">zeppieri@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Aug 5, 2016 at 6:32 PM, Jon Zeppieri <span dir="ltr"><<a href="mailto:zeppieri@gmail.com" target="_blank">zeppieri@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Aug 5, 2016 at 6:21 PM, Alexander Jones <span dir="ltr"><<a href="mailto:alex@weej.com" target="_blank">alex@weej.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Don't confuse timezones with timezone offsets. They are different concepts.</blockquote><div><br></div><div><br></div></span><span><div>How am I confusing them? You wrote: </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="color:rgb(80,0,80);font-size:12.8px">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.</span></blockquote><div><br></div></span><div>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.</div><span><font color="#888888"><div><br></div><div>- Jon</div><div></div></font></span></div></div></div></blockquote><div><br></div><div><br></div></div></div><div>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.</div><div><br></div><div>(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.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><span class=""><font color="#888888"><div><br></div><div>- Jon</div><div><br></div></font></span></div></div></div>
</blockquote></div><br></div></div>