On Mar 2, 2013, at 10:34 AM, Norbert Lindenberg <[email protected]> wrote:
> > On Mar 2, 2013, at 7:27 , Dean Landolt wrote: > >> I agree it doesn't make sense to solve this problem in the context of >> formatting, but there wouldn't be an issue if we had a way to set the zone >> of a Date. In another thread it was claimed that "A Date is intended to >> represent a specific instance in time, irrespective of time zone". But this >> isn't true at all -- a Date already carries around a timezone tag internally. > > What makes you believe that? According to the specification, the only data a > Date instance has is the [[PrimitiveValue]] internal property, which is a > time value, the number of milliseconds since 01 January, 1970 UTC: > http://ecma-international.org/ecma-262/5.1/#sec-15.9.6 > http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1 > > The Date constructor and the functions creating Date instances may accept > values expressed in the local time zone, but are all specified to calculate a > time value in UTC, which then gets stored in the [[PrimitiveValue]]. To speak to Dean's implications, many of the Date methods operate on the [[PrimitiveValue]] adjusted for an environmental local offset. Unless specifying obvious UTC versions (e.g. Date.getDay() vs Date.getUTCDay() So, it'd not that the local tz is carried around so much that all these methods rely on the environments. No? > >> And if you believe there's no use case for changing a date's timezone, try >> partitioning a set of Dates by day (or week, month, year, etc.) using a day >> boundary in a timezone other the current locale's or Zulu. I've come up >> against this use case more than once, and The solution sucks. It involves >> shipping some subset of the tz db to the client, which is ridiculous -- >> especially because there's an easy fix... > > That's a good use case, and you're right, it's currently not supported. > >> A zone tag already exists, if implicitly, on Dates. What's the harm in >> making it explicit -- exposing it as a unique symbol? It could be made >> writable, and a registry of IANA timezones could be exposed as symbols. > > According to the spec, there is no zone tag. Adding it would make simple > operations like comparing the time values of two Date instances a lot more > complicated, so I doubt we'd want to do that. I don't follow how this would make anything more/less complicated if comparison operated on the [[PrimitaveValue]]. Especially if everything just defaults to the way it works now (grab environment's local offset). However, I get not wanting to muck up existing API.. > > I think a better solution would be API that either lets you easily generate a > series of Date instances representing midnight (of every day, of every > Monday, of every first day of the month, ...) in a specified time zone and > calendar, or that lets you convert a Date to field-based time information in > a specified time zone and calendar so that you can apply your own criteria. Agree. > > Norbert > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss Jon Adams Sent from my Refrigerator _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
