Re: Override LocalTZA

2013-02-20 Thread Andrew Paprocki
The approach I've taken is to implement a native DateTz type which internally stores the UTC Date as well as the Date in the offset specified by either the user or an IANA timezone string. The non-UTC ES Date API then returns the local datetime in the specified timezone. The API is kept to a

Re: Override LocalTZA

2013-02-20 Thread Andrew Paprocki
I suppose I should add that the DateTz approach works only if you embed the IANA Olson tzdb with the engine rather than requiring the platform to provide it. Working with different timezones is problematic when going through libc (setting/resetting environment variables), and Windows does not use

Re: Override LocalTZA

2013-02-20 Thread Allen Wirfs-Brock
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

Re: Override LocalTZA

2013-02-20 Thread Andrew Paprocki
On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: What would be the best way to expose the localTZA for you purposes? Exposing localTZA at all would only lead to problems, IMO. class CST extends Date { get localTZA() {return -6*60*60*1000} } Timezones

Re: Override LocalTZA

2013-02-20 Thread Jonathan Adams
Excellent points and ideas here. I do think it would be extremely valuable to enable the ability to override any Date instance and don't think this is harmful. Not sure how reasonable/unreasonable requiring tzdb for vendors but seems worth it. Dates are important. Exposing something like

Re: Override LocalTZA

2013-02-20 Thread Andrew Paprocki
On Wed, Feb 20, 2013 at 11:03 AM, Jonathan Adams pointless...@me.comwrote: Date.setLocalTimezone('America/Los_Angeles') Date.getLocalTimezone() Since ES Dates represent single points in time (you can't have a time without a date or vice versa), there is no real reason to carry along a

get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013-02-20 Thread Tom Van Cutsem
2013/2/18 Andreas Rossberg rossb...@google.com On 16 February 2013 20:36, Allen Wirfs-Brock al...@wirfs-brock.com wrote: It's to simplify the MOP and that simplification is directly reflected as a simplification to the Proxy hander interface. Instead of 6 traps (preventExtensions,

Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 MeetingNotes)

2013-02-20 Thread Claus Reinke
I'd be interested to see your alternative design suggestion (or, in fact, any more general approach to the issue at hand that would fit into ES). From ES4, http://wiki.ecmascript.org/doku.php?id=proposals:static_generics. Thanks for the pointer. However, I'd like to have even more generic

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013-02-20 Thread Allen Wirfs-Brock
On Feb 20, 2013, at 9:24 AM, Tom Van Cutsem wrote: 2013/2/18 Andreas Rossberg rossb...@google.com On 16 February 2013 20:36, Allen Wirfs-Brock al...@wirfs-brock.com wrote: It's to simplify the MOP and that simplification is directly reflected as a simplification to the Proxy hander

Re: Override LocalTZA

2013-02-20 Thread Gillam, Richard
Wait a minute. I may be misunderstanding here, but all of this discussion sounds misguided to me. A Date is intended to represent a specific instance in time, irrespective of time zone. You don't want to go adding time-zone-related fields to the Date object. Time zone becomes important when

Re: Override LocalTZA

2013-02-20 Thread Gillam, Richard
Jon-- The current version of the spec is here: http://www.ecma-international.org/publications/standards/Ecma-402.htm What discussion takes place on this standard mostly takes place on this list, and TC39 is ultimately responsible for the standard, although there's an ad-hoc group that does

RE: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013-02-20 Thread Nathan Wall
Allen Wirfs-Brock wrote: I think I previously asked if anybody is aware of situations where  Object.isFrozen tests are done but Object.freeze is not used to set objects to the frozen state. So far, no answers. Anybody? Speaking just from my own experience as a user of ES5, I have not found

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013-02-20 Thread Kevin Reid
On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall nathan.w...@live.com wrote: `Object.isFrozen` and `Object.isSealed` don't really seem that helpful to me for the very reasons you've discussed: They don't represent any real object state, so they don't accurately tell me what can be done with an

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013-02-20 Thread David Bruant
Le 20/02/2013 21:08, Kevin Reid a écrit : On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall nathan.w...@live.com mailto:nathan.w...@live.com wrote: `Object.isFrozen` and `Object.isSealed` don't really seem that helpful to me for the very reasons you've discussed: They don't represent

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013-02-20 Thread Kevin Reid
On Wed, Feb 20, 2013 at 12:15 PM, David Bruant bruan...@gmail.com wrote: And in an ES6 world, you'll probably use an actual WeakMap anyway? Using an actual WeakMap does not change matters: the intent is that after Object.freeze(o), you can't add new trademarks to o. Since the trademark info is

RE: Override LocalTZA

2013-02-20 Thread Phillips, Addison
I agree that the tzinfo database and its identifiers should form the basis for ES time zone support. There are some issues with providing support, such as that it means that implementers will need to update several times a year (as time zone rules change). Setting TimeZone on a Date object

Re: Override LocalTZA

2013-02-20 Thread Norbert Lindenberg
The internationalization ad-hoc of TC 39 has already decided that edition 2 of the ECMAScript Internationalization API will support IANA time zone names in DateTimeFormat. Implementations will need to include best available information on all time zones or use equivalent operating system APIs.

Re: Override LocalTZA

2013-02-20 Thread Jonathan Adams
Absolutely. Now that I know this exists I completely agree with you. Would rather not muck up the Date api any more than it already is and the separation makes more sense. Thanks, all. -Jon- On Feb 20, 2013, at 3:08 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: Jon,

Re: Override LocalTZA

2013-02-20 Thread Andrew Paprocki
On Wed, Feb 20, 2013 at 6:08 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: Jon, Andrew: would a method similar to that operation address your needs? I agree that the conversion functionality is needed outside of formatting, but the issue for me is more complex. We have a

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013-02-20 Thread Mark S. Miller
(I do not yet have an overall opinion about get/setIntegrity. Here, I'm just answering and clarifying, not advocating.) On Wed, Feb 20, 2013 at 10:57 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: [...] Also, I'm concerned that we have been overloading the meaning of the [[Extensible]]

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013-02-20 Thread Brendan Eich
Allen Wirfs-Brock wrote: Actually, no. Reducing API complexity (in this case, the Proxy handler API) at the expense of a little bit of added spec. complexity seems like a very reasonable trade-off. Plus, we are talking about spec. complexity, not necessarily implementation complexity.

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013-02-20 Thread Tom Van Cutsem
2013/2/20 Allen Wirfs-Brock al...@wirfs-brock.com Finally, I still think we should further consider the feasibly of a breaking change where Object.preventExtensions(obj); for ( let k of Object.getOwnPropertyKeys(obj)) Object.defineProperty(obj,k,{configurable:false}); is no longer