Re: Override LocalTZA
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 minimum to avoid adding much on top of the ES Date: DateTz(msec, offset) DateTz.inTz(msec, tzstring) e.g. var a = new DateTz(Date.now(), -300); var b = DateTz.inTz(Date.now(), Asia/Tokyo); The returned objects simply proxy the public API of ES Date to the internal Date objects, so the above are the only real additions to the API surface. -Andrew On Wed, Feb 20, 2013 at 12:52 AM, Jonathan Adams pointless...@me.comwrote: 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Override LocalTZA
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 IANA strings. The DateTz trick only works because it is doing the IANA tzdb calculations itself and accessing its internal two ES Date objects (real UTC timestamp and one with the shifted UTC timestamp) via their UTC methods so that the engine itself does not attempt to do any translations. I would love to see something like DateTz be provided by the spec, but it means a shift to explicitly require native tzdb support by the engine rather than simply relying on the platform to handle conversions for whatever the current user's platform tz setting is. This then means implementations would have to stay up-to-date with tzdb releases (ala Java) to ensure they get proper DST updates. Maybe with the faster release cycles now used this is within the realm of possibility.. -Andrew On Wed, Feb 20, 2013 at 9:24 AM, Andrew Paprocki and...@ishiboo.com wrote: 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 minimum to avoid adding much on top of the ES Date: DateTz(msec, offset) DateTz.inTz(msec, tzstring) e.g. var a = new DateTz(Date.now(), -300); var b = DateTz.inTz(Date.now(), Asia/Tokyo); The returned objects simply proxy the public API of ES Date to the internal Date objects, so the above are the only real additions to the API surface. -Andrew On Wed, Feb 20, 2013 at 12:52 AM, Jonathan Adams pointless...@me.comwrote: 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Override LocalTZA
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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Override LocalTZA
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 can not be referred to as static offsets. The only error-free way
to deal with timezones is to store the string (e.g. Asia/Tokyo) and use
tzdb when performing conversion into another timezone (in this case, most
likely into UTC). UTC offset is a linear function that needs the full
datetime as input. Any other representation of it immediately introduces
bugs.
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?
Precisely why you need to either store a fixed offset (fixed point in time
-- and realize that is what you're doing) or you need to store the full
timezone string (in the case of recurring events). Recurring events could
not be hacked up with a localTZA modification. If a recurring meeting
occurs at 4pm every day in NY, America/New_York will needed to be used to
compute that in other timezones to avoid errors. Also, you don't even need
to get on a plane and fly. For example, if you live in the Middle East, you
are in the middle of a work day when the US EST/EDT shifts happen. If
you're referring to NY datetimes and using a fixed or precomputed offset
instead of treating the conversion as a linear function, there will be
errors.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Override LocalTZA
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
Date.setLocalTimezone('America/Los_Angeles')
Date.getLocalTimezone()
and leaving existing Date APIs untouched as well as preventing the guaranteed
problems of the natural inclination to pass static offsets seems perfect.
-Jon-
On Feb 20, 2013, at 7:03, Andrew Paprocki and...@ishiboo.com wrote:
On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
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 can not be referred to as static offsets. The only error-free way
to deal with timezones is to store the string (e.g. Asia/Tokyo) and use
tzdb when performing conversion into another timezone (in this case, most
likely into UTC). UTC offset is a linear function that needs the full
datetime as input. Any other representation of it immediately introduces bugs.
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?
Precisely why you need to either store a fixed offset (fixed point in time --
and realize that is what you're doing) or you need to store the full timezone
string (in the case of recurring events). Recurring events could not be
hacked up with a localTZA modification. If a recurring meeting occurs at 4pm
every day in NY, America/New_York will needed to be used to compute that in
other timezones to avoid errors. Also, you don't even need to get on a plane
and fly. For example, if you live in the Middle East, you are in the middle
of a work day when the US EST/EDT shifts happen. If you're referring to NY
datetimes and using a fixed or precomputed offset instead of treating the
conversion as a linear function, there will be errors.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Override LocalTZA
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
timezone string with each Date instance. This is why I took the approach of
having a static method to simply construct a shifted Date into a particular
timezone. Once the Date object is in that timezone, there is no need to
preserve the timezone string because there can only be one valid offset for
it. You only need to preserve the timezone string when storing a recurring
date/time and ES does not have any native representation of such a thing.
Also, sometimes you do need to preserve the static offset because a
timezone string is not provided. Parsing a SMTP mail header timestamp is an
example of this.
Keeping simple offset storage for a Date makes sense. Then there can be
higher level functions which allow you to create Dates in a particular
timezone or convert between two timezones by manipulating the stored
offset. Yes, someone can resort to manual offset fudgery and create DST
bugs, but hiding offset away would prevent people who *do* know what
they're doing what they need.
-Andrew
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
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, isExtensible, freeze, isFrozen, seal, isSealed) only two are needed. Also, having an explicit frozen object state simplifies some of the object invariants which would otherwise perform explicitly specified accesses to the target object which would be observable (if the target is itself a proxy). Well, that is either a breaking change, such that implementations can not actually be lazy about it, or it doesn't really remove complexity, since you still need to infer the state as a fallback (i.e., it's just an optimisation). I don't necessarily oppose making that breaking change, but we have to be aware that, even though it's an optimisation, the change is yet another complication of the object model. The additional state modifies the meaning of per-property descriptors on a second level. IIUC, defineProperty now has to check against that state, and getOwnPropertyDescriptor somehow has to take it into account, too. For direct proxies, the respective traps have to extend their validation logic. Overall, not a simplification, as far as I can see. I've been thinking some more about get/setIntegrity and I've come to the same conclusion. While get/setIntegrity gets rid of 4 traps (sealed/isSealed/frozen/isFrozen), it does so at the expense of extra complexity in other parts of the MOP, in particular, adding yet more state to check and update in [[GetOwnProperty]] and [[DefineOwnProperty]]. Allen, in light of this, wouldn't you agree that it's better to keep the extra traps? Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 MeetingNotes)
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 methods - e.g., map is useful for structures that do not have .length or indexed elements. To give you an idea of the possibilities I've got in mind, I've sketched an overly simplistic system where classes can implement interfaces, generic methods can be written over these implementations, and generic code can be written using only the generic methods. The code is available as https://gist.github.com/clausreinke/4997274 (you can run the html in a browser or with nodejs) It does implement map for Array, String and Int32Array (also for makePromise, if you're running this in nodejs, with q installed), without extending the classes or their objects (no mixins, and the generic map is class-independent and extensible). To understand why this is simplistic, think about the copymodify involved with doing this for all typed array variations - that is where class-level constructors and de-structurable classes would come in handy, so that one could separately reuse the array- and element-type-specific interface implementations (*). Claus (*) for those who do not switch off when they hear the word 'types' - even without a static type system, many of the ideas could be carried over from how Haskell implements type classes; it'll just be a little less convenient, and a little more explicit code to write; and it'll require some language design work to translate ideas away from the static typing context, into EcmaScript concepts; if you want to read Haskell papers for ES language design ideas, here are the beginnings of a little dictionary: for 'type', read 'class' for 'type class', read 'interface' for 'type class instance', read 'interface implementation' With this translation and the paper I referred to earlier in this thread, one notices that interfaces in Haskell tend to relate multiple classes, and that interface-implementing classes can often be de-structured (e.g., ArrayInt32 instead of Int32Array), to facilitate access to the interfaces implemented by the class components - that avoids a lot of duplicated code; ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
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 interface. Instead of 6 traps
(preventExtensions, isExtensible, freeze, isFrozen, seal, isSealed) only two
are needed.
Also, having an explicit frozen object state simplifies some of the object
invariants which would otherwise perform explicitly specified accesses to
the target object which would be observable (if the target is itself a
proxy).
Well, that is either a breaking change, such that implementations can
not actually be lazy about it, or it doesn't really remove complexity,
since you still need to infer the state as a fallback (i.e., it's just
an optimisation).
I don't necessarily oppose making that breaking change, but we have to
be aware that, even though it's an optimisation, the change is yet
another complication of the object model. The additional state
modifies the meaning of per-property descriptors on a second level.
IIUC, defineProperty now has to check against that state, and
getOwnPropertyDescriptor somehow has to take it into account, too. For
direct proxies, the respective traps have to extend their validation
logic. Overall, not a simplification, as far as I can see.
I've been thinking some more about get/setIntegrity and I've come to the same
conclusion. While get/setIntegrity gets rid of 4 traps
(sealed/isSealed/frozen/isFrozen), it does so at the expense of extra
complexity in other parts of the MOP, in particular, adding yet more state to
check and update in [[GetOwnProperty]] and [[DefineOwnProperty]].
Allen, in light of this, wouldn't you agree that it's better to keep the
extra traps?
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. An implementation is free to distribute
the complexity however it chooses. For example, if an implementation always
sets all of an objet's property descriptors to configurable: false when
[[SetIntegrity]](frozen) is performed (which Object.freeze is specified to do
in ES5) then there shouldn't be any extra work that needs to be done in the
ordinary implementations of [[GetOwnProperty]] or [[DefineOwnProperty]].
Also, I'm concerned that we have been overloading the meaning of the
[[Extensible]] state by hanging other meanings off of it, because it is the
only integrity state we currently have at the object level. For example, we
have tentative agreement at the timevalue of Date objects can not be modified
if [[Extensible]] is false and that RegExp.prototype.compile will not update an
RegExp instance if [[Extensible]] is false. Both of these seem like things
that would be better to associate with an explicit frozen object state. We
are also, from ES5, using [[Extensible]] to control whether [[Prototype]] can
be modified. This is a case where I think a new state might be appropriate as
it seems very reasonable for an object to want to fix [[Prototype]] but still
allow own properties to be added
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 equivalent to
Object.freeze(obj)
in terms of causing Object.isFrozen(obj) to return false.
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?
Allen
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Override LocalTZA
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 you're doing calculations on a time (converting it into year/month/day/hour/minute/second, etc.) or when you're converting it to a textual representation for display to the user. This is what the DateTimeFormat class in the ECMAScript internationalization spec is for, and it handles time zone. There's still a lot of work to do there, of course, but let's not break the whole model. --Rich Gillam Internationalization geek 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Override LocalTZA
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 most of the work. I don't remember if TC39's strawman pages are open, but there's discussion of the next version of ECMA 402 going on there. Good luck… --Rich Gillam Lab126 On Feb 20, 2013, at 11:38 AM, Jonathan Adams wrote: Rich, This sounds great. Yehuda Katz had hinted at this but the namespace is so polluted I was struggling to find anything official. Where can I go to follow this development? Jon Adams +1.530.908.1977 • skype: pointlessjon On Feb 20, 2013, at 11:32, Gillam, Richard gil...@lab126.com wrote: 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 you're doing calculations on a time (converting it into year/month/day/hour/minute/second, etc.) or when you're converting it to a textual representation for display to the user. This is what the DateTimeFormat class in the ECMAScript internationalization spec is for, and it handles time zone. There's still a lot of work to do there, of course, but let's not break the whole model. --Rich Gillam Internationalization geek 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
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 `Object.isFrozen` to be helpful yet. If I want to see if I can configure a property, I check `Object.isExtensible` and `!Object.prototype.hasOwnProperty.call(obj, key) || Object.getOwnPropertyDescriptor(obj, key).configurable`. `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 object. If I could I would argue in favor of their removal, though I know it's too late for that. I would be curious to see legitimate uses of `isFrozen` and `isSealed` in existing code if anyone has anything to offer. Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
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 object. If I could I would argue in favor of their removal, though I know it's too late for that. I would be curious to see legitimate uses of `isFrozen` and `isSealed` in existing code if anyone has anything to offer. I just took a look at uses of Object.isFrozen in Caja and I find that all but one are either in tests (test that something is frozen) or in sanity checks (if this isn't frozen, do not proceed further, or freeze it and warn). The remaining one is in a WeakMap abstraction used for trademarking: an object cannot be given a trademark after it is frozen. (The rationale here, while not written down, I assume is that a defensive object's “interface” should not change, and it is an implementation detail that this particular information is not stored in the object.) There is a comment there suggesting we might strengthen this check to only permitting _extensible_ objects to be marked. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
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 any real object state, so they don't accurately tell me what can be done with an object. If I could I would argue in favor of their removal, though I know it's too late for that. I would be curious to see legitimate uses of `isFrozen` and `isSealed` in existing code if anyone has anything to offer. I just took a look at uses of Object.isFrozen in Caja and I find that all but one are either in tests (test that something is frozen) or in sanity checks (if this isn't frozen, do not proceed further, or freeze it and warn). The remaining one is in a WeakMap abstraction used for trademarking: an object cannot be given a trademark after it is frozen. (The rationale here, while not written down, I assume is that a defensive object's interface should not change, and it is an implementation detail that this particular information is not stored in the object.) There is a comment there suggesting we might strengthen this check to only permitting _extensible_ objects to be marked. And in an ES6 world, you'll probably use an actual WeakMap anyway? Thanks for sharing this experience from Caja, David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
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 not stored on the object but in the WeakMap (whether emulated or actual), we have to add an explicit test. If 'private properties' (in whatever form they come to ES6) were available to us, then it would be natural to use them instead for this purpose (at least, so it seems to me at the moment) and so we would not need a test since non-extensibility would presumably reject the addition of a new private property. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Override LocalTZA
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 might not be the best design, even though
that’s sort of the design of Date today. Date values internally are actually
timestamps, “incremental time” [1] values---the number of millis since the
epoch date in UTC. Making the time zone a property of the date would be
confusing, since two incremental times are inherently comparable without
reference to LTO (local time offset) or time zone rules.
The problem is that many of the methods of Date expose “field values” within
the date—what is the day number or what is the hour number? Where TimeZones
need to be used is when transforming dates to/from display. This should apply
to the new Intl DateFormat stuff. Maybe adding methods that take a time zone or
adding a time zone class might be better? There is the problem that Date today
has separate methods that return the local value and the “GMT” value.
Addison
Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)
Internationalization is not a feature.
It is an architecture.
[1] http://www.w3.org/TR/timezone/#incrementaltime
From: Jonathan Adams [mailto:pointless...@me.com]
Sent: Wednesday, February 20, 2013 8:03 AM
To: Andrew Paprocki
Cc: es-discuss
Subject: Re: Override LocalTZA
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
Date.setLocalTimezone('America/Los_Angeles')
Date.getLocalTimezone()
and leaving existing Date APIs untouched as well as preventing the guaranteed
problems of the natural inclination to pass static offsets seems perfect.
-Jon-
On Feb 20, 2013, at 7:03, Andrew Paprocki
and...@ishiboo.commailto:and...@ishiboo.com wrote:
On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.commailto:al...@wirfs-brock.com wrote:
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 can not be referred to as static offsets. The only error-free way to
deal with timezones is to store the string (e.g. Asia/Tokyo) and use tzdb
when performing conversion into another timezone (in this case, most likely
into UTC). UTC offset is a linear function that needs the full datetime as
input. Any other representation of it immediately introduces bugs.
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?
Precisely why you need to either store a fixed offset (fixed point in time --
and realize that is what you're doing) or you need to store the full timezone
string (in the case of recurring events). Recurring events could not be hacked
up with a localTZA modification. If a recurring meeting occurs at 4pm every day
in NY, America/New_York will needed to be used to compute that in other
timezones to avoid errors. Also, you don't even need to get on a plane and fly.
For example, if you live in the Middle East, you are in the middle of a work
day when the US EST/EDT shifts happen. If you're referring to NY datetimes and
using a fixed or precomputed offset instead of treating the conversion as a
linear function, there will be errors.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Override LocalTZA
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.
I agree with Rich and Addison that adding a time zone to Date instances would
only create confusion. I think the best way to add general support for time
zones that's not tied to formatting would be methods that convert between
incremental time (a Date instance) and field-based time. Under the covers, the
Internationalization API spec already includes one direction as an abstract
operation:
http://www.ecma-international.org/ecma-402/1.0/index.html#ToLocalTime
Note that this operation also takes a calendar - this hasn't come up on this
thread yet, but is required because day/month/year values are always relative
to a calendar.
Jon, Andrew: would a method similar to that operation address your needs?
Norbert
On Feb 20, 2013, at 12:52 , Phillips, Addison wrote:
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 might not be the best design, even though
that’s sort of the design of Date today. Date values internally are actually
timestamps, “incremental time” [1] values---the number of millis since the
epoch date in UTC. Making the time zone a property of the date would be
confusing, since two incremental times are inherently comparable without
reference to LTO (local time offset) or time zone rules.
The problem is that many of the methods of Date expose “field values” within
the date—what is the day number or what is the hour number? Where TimeZones
need to be used is when transforming dates to/from display. This should apply
to the new Intl DateFormat stuff. Maybe adding methods that take a time zone
or adding a time zone class might be better? There is the problem that Date
today has separate methods that return the local value and the “GMT” value.
Addison
Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)
Internationalization is not a feature.
It is an architecture.
[1] http://www.w3.org/TR/timezone/#incrementaltime
From: Jonathan Adams [mailto:pointless...@me.com]
Sent: Wednesday, February 20, 2013 8:03 AM
To: Andrew Paprocki
Cc: es-discuss
Subject: Re: Override LocalTZA
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
Date.setLocalTimezone('America/Los_Angeles')
Date.getLocalTimezone()
and leaving existing Date APIs untouched as well as preventing the guaranteed
problems of the natural inclination to pass static offsets seems perfect.
-Jon-
On Feb 20, 2013, at 7:03, Andrew Paprocki and...@ishiboo.com wrote:
On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
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 can not be referred to as static offsets. The only error-free way
to deal with timezones is to store the string (e.g. Asia/Tokyo) and use
tzdb when performing conversion into another timezone (in this case, most
likely into UTC). UTC offset is a linear function that needs the full
datetime as input. Any other representation of it immediately introduces bugs.
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?
Precisely why you need to either store a fixed offset (fixed point in time --
and realize that is what you're doing) or you need to store the full timezone
string (in the case of recurring events). Recurring events could not be
hacked up with a localTZA modification. If a recurring meeting occurs at 4pm
every day in NY, America/New_York will needed to be used to compute that in
other timezones to avoid errors. Also, you don't even need to get on a plane
and fly. For example, if you live in the Middle East, you are in the middle
of a work day when the US EST/EDT shifts happen. If you're referring to NY
datetimes and using a fixed or precomputed offset instead of treating the
conversion as a linear function, there will be errors.
___
es-discuss mailing list
Re: Override LocalTZA
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, Andrew: would a method similar to that operation address your needs? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Override LocalTZA
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 vocabulary type consisting of [serial datetime, offset] used throughout our stack -- including both data services taking input from script and delivering output to script as well as native objects bound into script which use this vocabulary type in their API. In all those cases we don't have a way to pass individual fields. What is being proposed should be all that is needed for the browser world. I already modify the engine to override localTZA anyway because the platform timezone used by script is not the same as the timezone of the OS/user the engine is running as, so I'm used to being an exception.. :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
(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]] state by hanging other meanings off of it, because it is the
only integrity state we currently have at the object level. For example,
we have tentative agreement at the timevalue of Date objects can not be
modified if [[Extensible]] is false and that RegExp.prototype.compile will
not update an RegExp instance if [[Extensible]] is false. Both of these
seem like things that would be better to associate with an explicit
frozen object state.
Another instance of the same issue in a different guise is the restriction
in Object.observe (for ES7) that you cannot obtain from a frozen object the
right to notify its observers. In this case, in order to be more
permissive, we did attach the restriction to frozenness rather than just
extensibility. However, when frozenness is a complex test for a pattern of
restrictions that may or may not be accidental, this seems weird.
In other words, if an object is purposely frozen, no problem. But let's say
that in v1 of a program, object A is non-extensible, its foo property is
non-configurable, non-writable, and its bar property is writable. A later
refactoring realizes it doesn't need the bar property, and so deletes it.
It is weird that this would break previously correct code to obtain the
right to notify observers.
We are also, from ES5, using [[Extensible]] to control whether
[[Prototype]] can be modified. This is a case where I think a new state
might be appropriate as it seems very reasonable for an object to want to
fix [[Prototype]] but still allow own properties to be added
While sensible in theory, I don't think that case is worth yet another
state bit. If, like Object.observe, we had attached this restriction to
frozenness, we could not consider attaching this to an explicit frozenness
bit.
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 equivalent to
Object.freeze(obj)
in terms of causing Object.isFrozen(obj) to return false.
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?
I know of no uses of Object.isFrozen beyond those Kevin lists. None of
these would be broken by this change.
As for the rationale for the trademark restriction, more on that in a
separate email.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
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. Sure, but the spec is the first implementation. If implementors will not add another state bit (I predict they won't) then the spec is doing a disservice here. The Proxy API is complex already, due to ES5 in this case. It is not that much less complex with setIntegrity. I don't think the trade-off is worth it, and I suggest the all implementors ignore the spec complexity condition is one to avoid. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)
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 equivalent to
Object.freeze(obj)
in terms of causing Object.isFrozen(obj) to return false.
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?
I did a little code search via GitHub on uses of Object.isFrozen in JS
code. The large majority seems to occur in test cases (incl. Test262) or
libraries involving ES5 shims for ES3. There's no doubt this breaking
change will get noticed, as Test262 contains code such as:
assertEq(Object.isFrozen(Object.preventExtensions({})), true);
However, here and there you can find some code that branches on frozenness,
although it's not always clear what the rationale behind it is, e.g.:
https://github.com/petekinnecom/portfolio_chaplin/blob/b241300968fe6011c54548f24e0c8cfcd5d6d663/app/views/tube_view.coffee#L39
That said, I don't think this is enough evidence either for or against the
breaking change.
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
