Re: How primitive are Symbols? Bignums? etc
IIUC, the problem with symbols-as-primitives is that, on one hand, wrapper objects are not wanted, but, on the other hand, getting rid of wrappers leads to complications. My suggestion is to allow wrapper objects to exist in the spec, but to completely hide them from the user by doing an implicit unwrapping whenever applicable. Thus, for any primitive class `P` (such as `Symbol`, `Bignum`), except for legacy ones (`Number`, `Boolean` and `String`). * `new P` produces an unwrapped value; * `p = Object(p)` becomes a no-op; * `Object.defineProperty`, Object.getPrototypeOf`, etc., return an unwrapped value when applicable; * plus some further details I've forgotten. (Technically, I think naively that it suffices to define an `UnwrapIfNonLegacyPrimitive()` abstract operation and to apply it in correct places.) Moreover, in order to make primitives look more like objects, some adjustments could be done: * `instanceof` could wrap its LHS if it is a primitive value instead of throwing an error, so that tests like `s instanceof Symbol` would work; * Wrappers should be frozen at creation, so that things like `s.foo = 17` or `Object.setPrototypeOf(s, bar)` would fail noisily (at least in strict mode); * etc. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Resurrection] Make Function.length Configurable
No problem - I've enjoyed getting a glimpse into how this process works! On Wed, Jul 17, 2013 at 5:55 PM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, Jul 17, 2013 at 12:17 PM, Jeremy Martin jmar...@gmail.com wrote: An offline discussion with RW identified this as a spec bug. Filed here: https://bugs.ecmascript.org/show_bug.cgi?id=1587 Thanks again! (I see that Allen has already fixed this :D) Rick -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Andreas Rossberg wrote:
On 17 July 2013 21:10, Brendan Eichbren...@mozilla.com wrote:
We should not add more such user-facing pain if we can avoid it -- even if
that means more implementor-facing pain (remember Mr. Spock's Kobayashi Maru
solution ;-).
An inconsistency between strings and symbols is both a user-facing and
an implementor-facing pain.
Strings and symbols are quite different according to typeof and
behavior, in any proposal or implementation. How does providing a
wrapper which when used throws -- unlike ({}[new String('x')]) which
does not throw -- help make symbol like string in any user-facing sense?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Andreas Rossberg wrote:
On 18 July 2013 01:09, Brendan Eichbren...@mozilla.com wrote:
Brandon Benvie wrote:
On 7/17/2013 4:02 PM, Brandon Benvie wrote:
And this is how it currently works in the V8 implementation. The first
thing I did testing it looked like:
var s = new Symbol();
var x = {};
x[s] = 'test';
I was surprised to find that this threw an error instead of doing the (to
me) obvious thing.
(And to clarify, it throws on line 3, not line 1)
This is nuts.
May I humbly remind you that we explicitly discussed and decided this
at the March meeting?
If it's nuts now, it was nuts in March :-P.
I actually would have preferred if 'new Symbol'
worked, and that was what V8 implemented before the meeting.
You are right, I see this in the March 14 meeting notes. So I'm pleading
temporary insanity. We'll have to reestablish consensus. I will refrain
from more (self-)analysis ;-).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Brendan Eich wrote:
I actually would have preferred if 'new Symbol'
worked, and that was what V8 implemented before the meeting.
And just to be clear, what you implemented before the meeting, symbol
primitive with Symbol auto-wrapper and no throw on ({}[new Symbol])
seems better.
I think the issue some of us are having is auto-wrapping rather than
taking the value objects approach. If we are doing value objects as
discussed, then for symbols we have a choice: follow the string pattern,
or follow the int64, bignum, etc. proposal.
Of course value objects are not in ES6, and you may disagree on that
strawman's eschewing of auto-wrappers (I can't tell). Both of these
objections, whatever the ultimate disposition of value objects, seem to
me to be legitimate cause to favor the string pattern in ES6. But we
could be suffering from path dependence in taking this
shorter-term-conservative approach.
A separate issue with the string pattern: we do not want symbol objects
converting by toString, which motivated throwing instead. Claude just
suggested auto-unwrapping when used as a property name. I'll follow up
in reply to that sub-thread.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Andreas Rossberg wrote: On 18 July 2013 14:22, Claude Pacheclaude.pa...@gmail.com wrote: IIUC, the problem with symbols-as-primitives is that, on one hand, wrapper objects are not wanted, but, on the other hand, getting rid of wrappers leads to complications. My suggestion is to allow wrapper objects to exist in the spec, but to completely hide them from the user by doing an implicit unwrapping whenever applicable. Thus, for any primitive class `P` (such as `Symbol`, `Bignum`), except for legacy ones (`Number`, `Boolean` and `String`). * `new P` produces an unwrapped value; * `p = Object(p)` becomes a no-op; * `Object.defineProperty`, Object.getPrototypeOf`, etc., return an unwrapped value when applicable; * plus some further details I've forgotten. I'm not sure I understand what this would achieve. AFAICS, it is observably equivalent to making Symbol an object, no? So it would have the exact same implications. What implications do you object to, though. We have trouble making symbols like unforgeable strings. They must have distinct typeof-type -- a symbol can't be string according to typeof. We must avoid any wrapper converting to a string when used as a property name, per your ARB: The current spec has a toString for implicit conversion, which makes it too easy to convert the symbol to a string accidentally without realizing. from the March meeting notes. This leaves only three choices AFAICT: 1. Primitive symbol with Symbol auto-wrapper that throws when used as property name, the March consensus. 2. (1) but with Claude's suggestion: auto-unwrap on use of Symbol as property name. 3. Value object approach: no Symbol wrapper, typeof says symbol, spec treats symbol as exotic object per latest draft. Is there a 4th choice? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
On Jul 18, 2013, at 5:22 AM, Claude Pache wrote: IIUC, the problem with symbols-as-primitives is that, on one hand, wrapper objects are not wanted, but, on the other hand, getting rid of wrappers leads to complications. My suggestion is to allow wrapper objects to exist in the spec, but to completely hide them from the user by doing an implicit unwrapping whenever applicable. Thus, for any primitive class `P` (such as `Symbol`, `Bignum`), except for legacy ones (`Number`, `Boolean` and `String`). * `new P` produces an unwrapped value; * `p = Object(p)` becomes a no-op; * `Object.defineProperty`, Object.getPrototypeOf`, etc., return an unwrapped value when applicable; * plus some further details I've forgotten. (Technically, I think naively that it suffices to define an `UnwrapIfNonLegacyPrimitive()` abstract operation and to apply it in correct places.) Moreover, in order to make primitives look more like objects, some adjustments could be done: * `instanceof` could wrap its LHS if it is a primitive value instead of throwing an error, so that tests like `s instanceof Symbol` would work; * Wrappers should be frozen at creation, so that things like `s.foo = 17` or `Object.setPrototypeOf(s, bar)` would fail noisily (at least in strict mode); * etc. This is very similar to the the point I arrived at in trying to edit wrapper-less primitive symbols into the spec. However, I quickly realized that all these special cases are the equivalent of simply specifying symbols as exotic objects. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
On Jul 18, 2013, at 8:09 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
On 18 July 2013 01:09, Brendan Eichbren...@mozilla.com wrote:
Brandon Benvie wrote:
On 7/17/2013 4:02 PM, Brandon Benvie wrote:
And this is how it currently works in the V8 implementation. The first
thing I did testing it looked like:
var s = new Symbol();
var x = {};
x[s] = 'test';
I was surprised to find that this threw an error instead of doing the (to
me) obvious thing.
(And to clarify, it throws on line 3, not line 1)
This is nuts.
May I humbly remind you that we explicitly discussed and decided this
at the March meeting?
If it's nuts now, it was nuts in March :-P.
I actually would have preferred if 'new Symbol'
worked, and that was what V8 implemented before the meeting.
You are right, I see this in the March 14 meeting notes. So I'm pleading
temporary insanity. We'll have to reestablish consensus. I will refrain from
more (self-)analysis ;-).
No, you just need to read carefully, I remember that this is just a summary of
the discussion, not literal quotes, and not everything is captured:
AWB: Symbol is a factory that creates symbols, new Symbol creates instance of
the wrapper class. (same as Number)
BE: Value objects allow new
AWB: I can define the Symbol[@@create] to throw
I'm pretty sure that as part of the first statement I also said that 'new
Symbol' should not create a primitive value because that would violate the
wrapper object pattern.
The Synbol[@@create]] comment is another way of saying 'new Symbol' should
throw.
There is nothing following this in the Symbols section of the minutes that
address whether or not there are Symbol wrappers. My take-away from the meeting
was we would try to do Symbols as as a primitive, with a factory object named
'Symbol', but no user visible wrapper instances. I don't see anything in the
minutes that says otherwise. In fact, the conclusion/resolution doesn't even
say that Symbols will be primitive values. All of the bullet items listed
there are apply equally to either symbols as primitives or symbols as exotic
objects. The current (and previous, I believe) spec. draft reflects those
explicit conclusions.
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
On Jul 17, 2013, at 20:35 , Brendan Eich bren...@mozilla.com wrote: Norbert Lindenberg wrote: On Jul 17, 2013, at 17:27 , Mark S. Millererig...@google.com wrote: This is unfortunate. It does answer Anne's question though, in an unpleasant way: Date instances cannot be immutable; they can be at best readonly. Despite lack of any authorization to track the user's position, Date instances make visible their machine's mutable current position, as coarsened to the timezone. Just as a Date instance snapshots the time when it was created, I think it should also snapshot the timezone where it was created. Then it would be possible to contemplate immutable Date instances. Only the Date constructor should give the ability to sense changes to time and place, not the instances it makes. Virtualizing the Date constructor (replacing it with a faux Date constructor) should be adequate to create illusory paths through time and space, without needing to wrap all the instances it creates with faux Date instances. If you want to lock down the behavior of getTimezoneOffset, or create illusory behavior, Mark wants to do this from JS, not from under the hood (usually via C++) using VM internal APIs. Sorry, I missed that bit. In that case, you'd have to replace the Date function and all Date methods that depend on the local time zone: Date as a function; the Date constructor for 2 or more arguments; parse; toString friends; getFullYear, getMonth, and their non-UTC friends; getTimezoneOffset, setMilliseconds, setSeconds, and their non-UTC friends. That's a lot more work, but it still doesn't affect Date instances directly. Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
On Thu, Jul 18, 2013 at 12:44 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Jul 17, 2013, at 20:35 , Brendan Eich bren...@mozilla.com wrote: Norbert Lindenberg wrote: On Jul 17, 2013, at 17:27 , Mark S. Millererig...@google.com wrote: This is unfortunate. It does answer Anne's question though, in an unpleasant way: Date instances cannot be immutable; they can be at best readonly. Despite lack of any authorization to track the user's position, Date instances make visible their machine's mutable current position, as coarsened to the timezone. Just as a Date instance snapshots the time when it was created, I think it should also snapshot the timezone where it was created. Then it would be possible to contemplate immutable Date instances. Only the Date constructor should give the ability to sense changes to time and place, not the instances it makes. Virtualizing the Date constructor (replacing it with a faux Date constructor) should be adequate to create illusory paths through time and space, without needing to wrap all the instances it creates with faux Date instances. If you want to lock down the behavior of getTimezoneOffset, or create illusory behavior, Mark wants to do this from JS, not from under the hood (usually via C++) using VM internal APIs. Sorry, I missed that bit. In that case, you'd have to replace the Date function and all Date methods that depend on the local time zone: Date as a function; the Date constructor for 2 or more arguments; parse; toString friends; getFullYear, getMonth, and their non-UTC friends; getTimezoneOffset, setMilliseconds, setSeconds, and their non-UTC friends. That's a lot more work, but it still doesn't affect Date instances directly. *Or* the spec could redefine those functions to use an instance property lookup which defines the appropriate timezone. I'd suggested this several months back, and partly for this reason (it's also a much needed feature, and more idiomatically javascripty). Having Dates depend on an implicit global timezone is madness. Using a prototype property would allow Date objects to have their timezone explicitly set or modified, and they'd be possible to freeze. `Date.prototype.timezone` (or whatever it would be called) could then float with the system's timezone (or be explicitly set and/or frozen too). Oh, and this could be cleanly polyfilled to make dates and timezones suck less today. I still can't think of any downsides. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
On Jul 18, 2013, at 12:56 AM, Andreas Rossberg wrote:
On 18 July 2013 01:09, Brendan Eich bren...@mozilla.com wrote:
Brandon Benvie wrote:
On 7/17/2013 4:02 PM, Brandon Benvie wrote:
And this is how it currently works in the V8 implementation. The first
thing I did testing it looked like:
var s = new Symbol();
var x = {};
x[s] = 'test';
I was surprised to find that this threw an error instead of doing the (to
me) obvious thing.
(And to clarify, it throws on line 3, not line 1)
This is nuts.
May I humbly remind you that we explicitly discussed and decided this
at the March meeting? I actually would have preferred if 'new Symbol'
worked, and that was what V8 implemented before the meeting.
from the minutes:
AWB: I can define the Symbol[@@create] to throw
that means 'new Symbol' would throw.
But, as I mentioned in another message, I actually don't see in the minutes a
record of consensus one way or another regarding Symbol wrapper objects. I do
see push back against them and by I personally went away believing that we
agreed to try primitive symbols with no wrapper objects. If you look at the
Rev15 (May 2013) spec. draft the timestamp on the edits to introduce those
changes is March 18, 2013. So, I made those changes 4 days after the meeting
discussion and presumably with a fresh recollection of what transpired.
Seriously, all this discussion is about breaking the March consensus.
I find it rather irritating that some seem surprised about decisions
they actively had their part in. Moreover, I find it unacceptable when
the editor decides to break consensus single-handedly and implements
it without notice, let alone discussion.
Unfortunately, we don't even agree upon the details of the consensus. These
consensus agreements at meetings are important, and I always try to get them
into the spec. draft as soon as possible. However, they are typically made in
the context of a relatively short debate where it is impossible for everybody
to explore and understand all the deep implications of a decision. Sometimes
we reach a consensus that latter proves to be problematic.
I have to take the result of those decisions and try to make them work in the
spec. and implementors should be trying to make them work in their engines. I
immediately incorporated the my understanding of the consensus into what was
ultimately released as the May draft. After that I started to routinely
discover numerous additional special cases in the spec. where primitive symbols
had to be explicitly accounted for and also discovered that it was something
that I was having to consider (or was forgetting to consider) as I added new
material to the spec. My conclusion, was that primitive symbols without
wrappers wasn't going to work.
I know I informally talked about this with several people. I reverted symbol to
being an exotic object May 29 shortly after getting back from the May TC39
meeting so something that came out of that meeting pushed me over the edge
towards reverting. I think it probably was things I ran into while changing
function call to use [[Invoke]].
At a meta level, I need to keep moving forward on the spec. or it will never be
completed. We seldom are able to definitively resolve issues on es-discuss and
I can't let myself get blocked for up to two months waiting for a TC39 meeting.
So I have to make make informed guesses about ultimate outcomes and use them
in my working drafts so I can move forward with a reasonably self-consistent
spec. Every thing in the draft spec is subject to (and needs) serious review
by TC39 members. As I say quite often, nothing in the spec. if final until the
entire thing is approved by TC39. (BTW, I really appreciate the stream of good
feedback continue to get from the V8 team via bugs.ecmascript.org).
In this particular case, I guessed that we were going to ultimately either go
back to Symbols as objects or to introduce wrapper objects for primitive
Symbols. So, I had basically three choices: 1) keep going with special case
handling of primitive symbols scattered through out the spec. 2) Revert to a
centralized definition of exotic symbol objects, 3) add symbol wrappers.
option 1 was the maintenance nightmare I was trying to recover from. I
believed there was strong opposition to adding additional wrapper objects, so I
didn't want to push a Symbol wrapper into the spec. yet. But it turns out that
option 2, was also a reasonable place for moving to option 3 if we decided to
go that route (both option 23 eliminates most of the special case handling).
So, that's where we stand today. I'm betting that TC39 will ultimately decide
on either symbols as exotic objects or primitive symbols with wrappers. The
current state of the spec. makes it easy for me to go either direction.
allen___
es-discuss mailing list
es-discuss@mozilla.org
Unicode aliases for ASCII operators
I was thinking about this subject a while ago and found an interesting thread [1] on the Scala debate mailing list. I was going to raise this question back then, but I forgot about it until now. If I understand correctly, several Unicode symbols are aliases for ASCII operators, for example: = ⇒ // implemented - ← // implemented - → // implemented At the time I saw this, I thought it was pretty interesting. The thread goes on to suggest more could be implemented: = ≥ = ≤ * × multiplication // this one's probably an ASCII approximation / ÷ division ! ¬ logical negation ^ ⊕ exclusive or != ≠ not equal Perhaps we could think about this for ECMAScript, along with the rest(e.g. ≈ for == and ≡ for ===). Would there be any harm in it if we kept the ASCII equivalents intact? By putting them in we may be looking toward the future where this kind of thing is (hopefully) more common in programming languages (and on keyboards). Andy [1] http://www.scala-lang.org/node/4723 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Allen Wirfs-Brock wrote:
On Jul 18, 2013, at 8:09 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
On 18 July 2013 01:09, Brendan Eichbren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Brandon Benvie wrote:
On 7/17/2013 4:02 PM, Brandon Benvie wrote:
And this is how it currently works in the V8 implementation. The
first
thing I did testing it looked like:
var s = new Symbol();
var x = {};
x[s] = 'test';
I was surprised to find that this threw an error instead of doing
the (to
me) obvious thing.
(And to clarify, it throws on line 3, not line 1)
This is nuts.
May I humbly remind you that we explicitly discussed and decided this
at the March meeting?
If it's nuts now, it was nuts in March :-P.
I actually would have preferred if 'new Symbol'
worked, and that was what V8 implemented before the meeting.
You are right, I see this in the March 14 meeting notes. So I'm
pleading temporary insanity. We'll have to reestablish consensus. I
will refrain from more (self-)analysis ;-).
No, you just need to read carefully,
Do you mean me, or Andreas? Or Rick who took the meeting notes?
The notes should not require reading between the lines, including your
unrecorded statements! Not that notes are ever perfect.
Ok, everyone take a deep breath
I remember that this is just a summary of the discussion, not literal
quotes, and not everything is captured:
AWB: |Symbol| is a factory that creates symbols, |new Symbol|
creates instance of the wrapper class. (same as Number)
BE: Value objects allow new
AWB: I can define the |Symbol[@@create]| to throw
I'm pretty sure that as part of the first statement I also said that
'new Symbol' should not create a primitive value because that would
violate the wrapper object pattern.
The Synbol[@@create]] comment is another way of saying 'new Symbol'
should throw.
Yes, and (whether it was March or May -- March I think) we did talk
about value object constructors not supporting 'new'.
There is nothing following this in the Symbols section of the minutes
that address whether or not there are Symbol wrappers. My take-away
from the meeting was we would try to do Symbols as as a primitive,
with a factory object named 'Symbol', but no user visible wrapper
instances. I don't see anything in the minutes that says otherwise.
In fact, the conclusion/resolution doesn't even say that Symbols will
be primitive values. All of the bullet items listed there are apply
equally to either symbols as primitives or symbols as exotic objects.
The current (and previous, I believe) spec. draft reflects those
explicit conclusions.
Ok, but we clearly had two people (at least) at the meeting who came to
quite different conclusions. That's a problem. These things happen,
we'll sort it out, but I'm not sure what you are doing here other than
reiterating what you got from the notes. The notes are incomplete, in a
way that supports multiple conflicting interpretations.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Chained comparisons from Python and CoffeeScript
I apologise if I'm making more suggestions that have been discussed in the past, I'm genuinely searching before I click the compose button and not finding anything! I'd like to see this implemented, at least for greater/less than (-or equal to). a b c a = b = c Desugars to a b b c a = b b = c For a real-world example var pos = element.getBoundingClientRect(), inView = 0 = pos.left pos.left = window.innerWidth 0 = pos.top pos.top = window.innerHeight; Could be rewritten as var pos = element.getBoundingClientRect(), inView = 0 = pos.left = window.innerWidth 0 = pos.top = window.innerHeight; There's a lot to be said for readability, and each operand needs only be evaluated once, so it could help avoid the need for creating variables to store the result of a function or a getter (or prevent the need for either to be invoked more than once). It's also supported (as the title suggests) by Python [1], Perl 6 [2] and CoffeeScript [3]. Those languages support chaining the equality operators too. It's potentially a breaking change, because 0 1 1 evaluates to false in current implementations because (0 1) 1 However, I think we'd be hard pressed to find code like this with greater/less than or equality operators. [1] http://docs.python.org/2/reference/expressions.html#not-in [2] http://en.wikipedia.org/wiki/Perl_6#Chained_comparisons [3] http://coffeescript.org/#comparisons ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Time zone changes in Date
On Jul 19, 2013, at 0:41 , Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Jul 17, 2013, at 20:29 , Brendan Eich bren...@mozilla.com wrote: Norbert Lindenberg wrote: On Jul 17, 2013, at 13:58 , Brendan Eichbren...@mozilla.com wrote: No, *time* is stored as milliseconds after the epoch in a number (IEEE double). A Date object includes position on planet and timezone politics (see getTimezoneOffset). No, it doesn't. Any time zone information used by getTimeZoneOffset and other non-UTC Date API is based on time zone information in the environment: the local time zone is typically what the user has told the OS to use. A Date object itself only wraps the time value. No. This is not well-specified by ECMA-262, implementations do crack time to date fields in Date instances, and one's timezone can change in a running system (say a Firefox OS phone one takes on a plane). Implementations are free to cache all kinds of things to improve performance, but they still have to produce the specified behavior. The behavior of Date non-UTC methods is defined in terms of a single time value and conversion functions that rely on local time zone adjustment and local daylight saving time adjustment. The spec text varies a bit between ES5 and ES6, but my interpretation of both would be that when the local time zone changes, the results of LocalTZA, DaylightSavingTA, and LocalTime all change, so caches based on them have to be invalidated. If some or all implementations have interpreted that differently, then the spec needs to be clarified one way or another. I did some testing, and found some random behavior in reaction to time zone changes. The test is here: http://norbertlindenberg.com/ecmascript/DateTest.html The test runs for one minute, printing the results of calling toString, getHours, getTimezoneOffset, and (if the Internationalization API is enabled) toLocaleString on two Date instances every 5 seconds. One instance is reused for the entire time; another is created anew each iteration. For each test run, I manually perform the following steps: 1) launch the browser while the OS time zone is set to America/Los_Angeles (PDT), 2) start the test, let it log at least once, 3) change the operating system's time zone to Europe/Berlin (CEST), let it log at least once, 4) open a new browser window, let it log at least once, 5) switch the OS time zone back to PDT, let it log at least once. Note that toString in Chrome, Firefox, and Safari prints two time zone identifiers, one of the form GMT+/-, one a more conventional abbreviation. I'll call the first tz1, the second tz2. At step 2, All browsers display reasonable information about the Date instances in PDT. After that, they all go different paths. Chrome 28 / Mac (has Internationalization API): - At step 3, tz2 for both Date instances changes from PDT to UTC. UTC is not the new time zone, and the only way to change it again to anything other than UTC is by relaunching the browser. - Nothing else ever changes. Firefox Nightly + Internationalization API / Mac: - At step 3, tz2 for both Date instances changes from PDT to CEST. - At step 4, all remaining output except toLocaleString for both Date instances changes from PDT to CEST. - At step 5, tz2 for both Date instances changes back from CEST to PDT. - The output of toLocaleString stays in PDT throughout. Internet Explorer 10 (no Internationalization API): - At step 3, all information for new Date instances changes from PDT to CEST (labeled UTC+0200). - At step 5, all information for new Date instances changes back from CEST to PDT. Safari 6.0.5 (no Internationalization API): - At step 3, tz2 for the reused Date instance changes from PDT to CEST, and all information for new Date instances changes from PDT to CEST. - At step 5, tz2 for the reused Date instance changes back from CEST to PDT, and all information for new Date instances changes back from CEST to PDT. Bugs as I'd see them: - Chrome, Firefox, Safari: The string returned by toString() can contain a tz2 that indicates a time zone that's different from tz1 and doesn't match the time zone assumed for other parts of the string. - Firefox: toLocaleString() can use a different time zone than other Date methods. - Explorer, Safari: Different Date instances can assume different time zones at the same time. Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
