> > > > 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?
That’s correct, but those methods are also misleading and probably not something one would design for the Date class if designing it today. The proposal provides a better means for extracting calendar- and locale-specific field values from a Date object because it allows for calendar variation, local rule variation (start of week, week number, etc.), and for the application of time zone (either explicitly or implicitly). The addition of time zones will allow developers to get not only client-local values, but also to specify a time zone, as many applications require. FWIW, the W3C I18N WG maintains a Note about some of the issues of working with time zones on the Web [1] which I think is helpful when talking about this topic. If you go through the use cases (Norbert, by the way, contributed them to that document), you can see that adding a time zone value to a Date is insufficient for some cases and is overkill for others. I don't think that formally defining time zones would alter the behavior of the getXXX methods, but then the getXXX methods are not sufficient for what you (and I and others) want/need to do anyway. > > > >> 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.. If a Date is simply a wrapper around an epochal-time value (what the document I mentioned calls an "incremental time"), then most time-based operations on the primitive value becomes straightforward (comparison, equality, assignment, etc.). The value has no "time zone" inherent in it, since it is the same time in UTC everywhere that time is measured. The time zone only matters when extracting calendric field values (day, month, hour, etc.) and, as noted just below, this works better when applied externally. Indeed, it allows the same Date object to be handled in multiple time zones simultaneously, without altering the value itself. It does mean that the time zone must be passed as a separate variable if the time zone is important to the operations that will be performed on time values. > > > > > 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. > > Addison [1] http://www.w3.org/TR/timezone/ Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
