What would be the best way to expose the localTZA for you purposes?
At one extreme, we have could add get/setLocalTZA methods to Date.prototype.
This would allow the localTZA of any date instance to be dynamically queried
or modified (even multiple times). However, this might be more flexibility
then is desirable. For example, anytime you pass a date object as a parameter
there would be the potential that the local TZA could be modified. Of course,
pretty much every other component of a date an be modified so maybe this isn't
really a new problem.
Another approach would build off of the subclassability of Date in ES6.
localTZA could be defined as a ready only accessor property on Date.prototype
that delivers that system default. However, you could define a subclass with a
different localTZA;
class CST extends Date {
get localTZA() {return -6*60*60*1000}
}
then all instances of CST would use the supplied localTZA.
Any preferences? Are there any other values that we need to similarly expose?
Perhaps DaylightSavingsTA?
If we're mucking in this area, I wonder if there are other issues we should
think about.
One of my concerns is the reliability of these values in long running mobile
programs. Consider that I'm running a WebApp on my laptop and have created a
bunch of date objects. I then put my laptop to sleep and travel across several
timezones before waking it up and resuming the program. What is the localTZA
of those preexisting date instances. Was it fixed when they were created or is
the default localTZA potentially dynamically updated. What would an
application want to happen?
Allen
On Feb 19, 2013, at 9:52 PM, Jonathan Adams wrote:
> I understand that an implementation of ECMAScript is expected to determine
> the local time zone adjustment [1].
>
> This is really convenient -- most of the time. However, it would be great to
> override this for a given Date object. It doesn't appear that we can at the
> moment [2] or in ES6.
>
> If we could override this context, we can then take advantage of some of the
> other native methods such as Date.toString(), Date.getDate() etc. using our
> preferred, altered LocalTZA rather than users having to build horrible
> user-land functions [3] and wrestle with daylight savings time adjustments
> [4].
>
> My particular use-case involves taking dates generated in CST, stored as UTC
> (this is good) but then I want to offer a list of dates relative to CST, but
> this is processed in a context with LocalTZA for PST. I can get away with
> faking it by calculating the difference in timezones and altering the
> timestamp used to generate a new Date object but, this is going to
> technically be off at some points in time (DST adjustment for example) and
> feels wrong/hacky.
>
> -Jon-
>
> [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.9.1.7
> [2]
> http://stackoverflow.com/questions/9369972/can-i-set-the-local-timezone-in-my-browser-via-javascript
> [3]
> http://www.techrepublic.com/article/convert-the-local-time-to-another-time-zone-with-this-javascript/6016329
> [4] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013322.html
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
