Allen Wirfs-Brock (2013-02-20T14:51:33.000Z)
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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
github at esdiscuss.org (2013-07-12T02:26:27.564Z)
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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>