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 <[email protected]> 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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
