Re: Internationalization: Support for IANA time zones
T here are two different issues: Zone - what we do in CLDR solves the issue. All implementations should, and as far as I know, do, accept all of the valid TZIDs. Because we use existing valid TZIDs as the canonical form, even though they are not the same as in the Zone file, it all works. And we in EcmaScript can reference the CLDR IDs without requiring the use of any of the localization data; they are maintained in the timezone.xml file, eg: http://unicode.org/repos/cldr/tags/release-22-1/common/bcp47/timezone.xml We have also developed and maintain the short unique IDs that you see there, so that the Olson TZIDs can be used in locale tags. Disappearing IDs. Yes, the best that can be done for that is to keep any old ones despite what the IANA registry does, and deprecate them. That's also what we do in BCP47 with disappearing ISO codes (ugg). The downside here is that a different implementation of the IANA timezone APIs may drop support for the old ones. So we have to decide whether that is a requirement of implementations or not. Mark https://plus.google.com/114199149796022210033 * * *— Il meglio è l’inimico del bene —* ** On Fri, Mar 1, 2013 at 9:40 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: The identifier issues first: On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote: These names are canonicalized to the corresponding Zone name in the casing used Because the Zone names are unstable, in CLDR we adopted the same convention as in BCP47. That is, our canonical form never changes, no matter what happens to Zone names. I'd strongly recommend using those as the canonical names to prevent instabilities. The lack of stability in these identifiers is a problem. I don't see however how creating our own set (or using a set defined by CLDR) would help with interoperability with other systems based on IANA time zone names. It reminds me of how the Java Locale class was specified in 1997 to use language codes for three languages that ISO had deprecated years earlier, forcing Java developers to deal with an incompatibility between the Java world (including down to the file names of resource bundles) and the rest of the world. Has anybody tried to correct this at the source, by writing an RFC with maintenance rules for the names in the time zone database, similar to what's in BCP 47? How did the folks on the tz mailing list react? reject strings that are not registered That is another problem, since the TZ database does not guarantee non-removal (and has removed IDs). This one could be corrected by allowing as input all names that were in the time zone database at any time after a given date, e.g. after IANA took over, and treating them as Link names. Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: Support for IANA time zones
It seems we have agreement that the canonicalized IANA names are not good for formatted strings. I like the CLDR solution, but see it as implementation dependent. *Maybe there's just no value in trying to define something in the standard since any implementer can claim that Center, North Dakota and GMT+09:00 are localized representations for some locale. * So, leave it all implementation dependent? I agree. (And you hit on an important point above.) Mark https://plus.google.com/114199149796022210033 * * *— Il meglio è l’inimico del bene —* ** On Fri, Mar 1, 2013 at 10:33 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: And the time zone names in formatted output when no localized time zone name is available: On Feb 28, 2013, at 15:35 , Norbert Lindenberg wrote: 5) The set of combinations of time zone name and language tag for which localized time zone names are available is implementation dependent. Where no localized time zone name is available, the canonicalized name is used in formatted output. The last one I'm not entirely comfortable with: IANA time zone names can be long and unfamiliar (e.g., America/Indiana/Tell_City), and sometimes people think the wrong representative city was selected (e.g., Shanghai rather than Beijing for China). An alternative might be to prescribe formatting as an offset from UTC. On Feb 28, 2013, at 16:13 , Shawn Steele wrote: For #5 I might prefer falling back to English or something. I don't think UTC offset is a good idea because that doesn't really represent a Timezone very well. (If a meeting gets moved to a following week, that offset might change or be wrong) On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote: This is a problematic. The canonicalized names are very ugly. What we do in CLDR is return the last label, after some modifications (in http://www.unicode.org/repos/cldr/trunk/common/main/root.xml). We don't want to return the raw IDs. I think this needs to be implementation dependent. For example: zone type=Antarctica/DumontDUrville exemplarCityDumont d’Urville/exemplarCity /zone zone type=America/North_Dakota/Center exemplarCityCenter, North Dakota/exemplarCity /zone So I think we should just have #5 be: 5) The set of combinations of time zone name and language tag for which localized time zone names are available is implementation dependent. On Mar 1, 2013, at 9:41 , Phillips, Addison wrote: I think the least surprise would result if the GMT+/- string were used when no local representation is available. While the actually time zone is more specific, most callers are just trying to put a date or time value into their output for human consumption. In most cases, the DST transition rules are unimportant to a specific date value being rendered and the GMT offset is at least somewhat compact. Users are probably more familiar with this presentation and certainly will be happier with it than America/Los_Angeles. It seems we have agreement that the canonicalized IANA names are not good for formatted strings. I like the CLDR solution, but see it as implementation dependent. Maybe there's just no value in trying to define something in the standard since any implementer can claim that Center, North Dakota and GMT+09:00 are localized representations for some locale. So, leave it all implementation dependent? Norbert ___ 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: What is the status of Weak References?
Le 02/03/2013 01:58, Rafael Weinstein a écrit : On Sat, Feb 2, 2013 at 11:02 AM, Brendan Eich bren...@mozilla.com wrote: David Bruant wrote: Interestingly, revocable proxies require their creator to think to the lifecycle of the object to the point where they know when the object shouldn't be used anymore by whoever they shared the proxy with. I feel this is the exact same reflections that is needed to understand when an object isn't needed anymore within a trust boundary... seriously questioning the need for weak references. Sorry, but this is naive. Real systems such as COM, XPCOM, Java, and C# support weak references for good reasons. One cannot do data binding transparently without either making a leak or requiring manual dispose (or polling hacks), precisely because the lifecycle of the model and view data are not known to one another, and should not be coupled. See http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs intro, on the observer and publish-subscribe patterns. This is exactly right. I'm preparing an implementation report on Object.observe for the next meeting, and in it I'll include findings from producing a general purpose observation library which uses Object.observe as a primitive and exposes the kind of semantics that databinding patterns are likely to need. Without WeakRefs, observation will require a dispose() step in order to allow garbage collection of observed objects, which is (obviously) very far from ideal. There is another approach taken by the requestAnimationFrame API that consists in one-time event listeners (Node.js also has that concept too [1]), requiring to re-subscribe if one wants to listen more than once. I wonder why this approach has been taken for requestAnimationFrame which is fired relatively often (60 times a second). I'll ask on public-webapps. I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. I'm looking forward to reading your findings in the meeting notes. David [1] http://nodejs.org/api/events.html#events_emitter_once_event_listener ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: What is the status of Weak References?
I don't understand how the requestAnimationFrame approach (to registering periodic callbacks) applies to scenarios where you want Weak References (for lifetime management) or to observe an object (for notifications in response to actions by other arbitrary code that has a reference to an object). These seem to be significantly different problems with different constraints. If anything, requestAnimationFrame is an example of an API that poorly expresses developer intent. It is rare for someone to actually only ever want to render a single animation frame; furthermore most animation scenarios in fact require rendering a series of frames on consistent timing. Furthermore, the need to manually trigger further frame callbacks is error-prone - you are essentially offloading the cost of lifetime management onto the application developer, by making them manually manage the lifetime of their callback on an ongoing basis by having to remember to say 'please keep my animation alive' at the right time every frame no matter what, which probably means a try block and auditing their rAF callback to ensure that all exit paths call rAF again. I suspect that if you were to look at most applications that use rAF, you would find very few of them intentionally stop running animation frames in any scenario other than the termination of the application. For this and other reasons, I would suggest that it is a horrible idea to use rAF as an example of how to design an API or solve developer problems - especially problems as important as those addressed by weak references. -kg On Sat, Mar 2, 2013 at 2:58 AM, David Bruant bruan...@gmail.com wrote: Le 02/03/2013 01:58, Rafael Weinstein a écrit : On Sat, Feb 2, 2013 at 11:02 AM, Brendan Eich bren...@mozilla.com wrote: David Bruant wrote: Interestingly, revocable proxies require their creator to think to the lifecycle of the object to the point where they know when the object shouldn't be used anymore by whoever they shared the proxy with. I feel this is the exact same reflections that is needed to understand when an object isn't needed anymore within a trust boundary... seriously questioning the need for weak references. Sorry, but this is naive. Real systems such as COM, XPCOM, Java, and C# support weak references for good reasons. One cannot do data binding transparently without either making a leak or requiring manual dispose (or polling hacks), precisely because the lifecycle of the model and view data are not known to one another, and should not be coupled. See http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs intro, on the observer and publish-subscribe patterns. This is exactly right. I'm preparing an implementation report on Object.observe for the next meeting, and in it I'll include findings from producing a general purpose observation library which uses Object.observe as a primitive and exposes the kind of semantics that databinding patterns are likely to need. Without WeakRefs, observation will require a dispose() step in order to allow garbage collection of observed objects, which is (obviously) very far from ideal. There is another approach taken by the requestAnimationFrame API that consists in one-time event listeners (Node.js also has that concept too [1]), requiring to re-subscribe if one wants to listen more than once. I wonder why this approach has been taken for requestAnimationFrame which is fired relatively often (60 times a second). I'll ask on public-webapps. I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. I'm looking forward to reading your findings in the meeting notes. David [1] http://nodejs.org/api/events.html#events_emitter_once_event_listener ___ 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: What is the status of Weak References?
On Sat, Mar 2, 2013 at 6:11 AM, Kevin Gadd kevin.g...@gmail.com wrote: I don't understand how the requestAnimationFrame approach (to registering periodic callbacks) applies to scenarios where you want Weak References (for lifetime management) or to observe an object (for notifications in response to actions by other arbitrary code that has a reference to an object). These seem to be significantly different problems with different constraints. If anything, requestAnimationFrame is an example of an API that poorly expresses developer intent. It is rare for someone to actually only ever want to render a single animation frame; furthermore most animation scenarios in fact require rendering a series of frames on consistent timing. Furthermore, the need to manually trigger further frame callbacks is error-prone - you are essentially offloading the cost of lifetime management onto the application developer, by making them manually manage the lifetime of their callback on an ongoing basis by having to remember to say 'please keep my animation alive' at the right time every frame no matter what, which probably means a try block and auditing their rAF callback to ensure that all exit paths call rAF again. I suspect that if you were to look at most applications that use rAF, you would find very few of them intentionally stop running animation frames in any scenario other than the termination of the application. For this and other reasons, I would suggest that it is a horrible idea to use rAF as an example of how to design an API or solve developer problems - especially problems as important as those addressed by weak references. One positive aspect about the rAF approach is that if an error occurs in the callback, the animation will stop instead of potentially leading the application into an inconsistent state and flooding the console, making debugging more painful. That said, I hardly ever use rAF directly, but instead usually a wrapper library that handles animation continuity, fps calculation etc. Perhaps rAF was meant to be consumed as a low-level API by animation libraries. Cheers, Jussi -kg On Sat, Mar 2, 2013 at 2:58 AM, David Bruant bruan...@gmail.com wrote: Le 02/03/2013 01:58, Rafael Weinstein a écrit : On Sat, Feb 2, 2013 at 11:02 AM, Brendan Eich bren...@mozilla.com wrote: David Bruant wrote: Interestingly, revocable proxies require their creator to think to the lifecycle of the object to the point where they know when the object shouldn't be used anymore by whoever they shared the proxy with. I feel this is the exact same reflections that is needed to understand when an object isn't needed anymore within a trust boundary... seriously questioning the need for weak references. Sorry, but this is naive. Real systems such as COM, XPCOM, Java, and C# support weak references for good reasons. One cannot do data binding transparently without either making a leak or requiring manual dispose (or polling hacks), precisely because the lifecycle of the model and view data are not known to one another, and should not be coupled. See http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs intro, on the observer and publish-subscribe patterns. This is exactly right. I'm preparing an implementation report on Object.observe for the next meeting, and in it I'll include findings from producing a general purpose observation library which uses Object.observe as a primitive and exposes the kind of semantics that databinding patterns are likely to need. Without WeakRefs, observation will require a dispose() step in order to allow garbage collection of observed objects, which is (obviously) very far from ideal. There is another approach taken by the requestAnimationFrame API that consists in one-time event listeners (Node.js also has that concept too [1]), requiring to re-subscribe if one wants to listen more than once. I wonder why this approach has been taken for requestAnimationFrame which is fired relatively often (60 times a second). I'll ask on public-webapps. I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. I'm looking forward to reading your findings in the meeting notes. David [1] http://nodejs.org/api/events.html#events_emitter_once_event_listener ___ 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: What is the status of Weak References?
Le 02/03/2013 12:11, Kevin Gadd a écrit : I don't understand how the requestAnimationFrame approach (to registering periodic callbacks) applies to scenarios where you want Weak References (for lifetime management) or to observe an object (for notifications in response to actions by other arbitrary code that has a reference to an object). These seem to be significantly different problems with different constraints. It's not really about periodic, but rather about the idea of a one time listener. The reason I talked about 60 frames per second is that it's an event that's fired very often, so it may have a significant cost something at runtime to conditionally re-register. The general problem is to know when someone listening actually wants to stop listening. Currently, the default of observing is observe ad vitam æternam which obviously causes the issue of what if actually it's been long that we didn't want to observe? The one time listener approach is interesting, because it doesn't say observe ad vitam æternam, but rather I'll call you only once, figure out the rest on your own (so, re-subscribe if that's what you want). On the huge benefits of this approach, the problem of GC-ing observers is completely solved by the API. Well, not exactly. Maybe you registered, but don't care before the event happens, so your observer is garbage until called once. But after the event happens, it can be released. In a way, a one-time listener can be seen as an auto-wrapped (wrapped by the event emitter, not the one who registered it) one-time reference (very weak reference?). If anything, requestAnimationFrame is an example of an API that poorly expresses developer intent. I've asked [1], we'll see. I'm not very interested in rAF specifically, because I mostly agree with you that from all the code snippets I've read and written, people re-subscribe unconditionally. Maybe some more complex applications don't. Furthermore, the need to manually trigger further frame callbacks is error-prone - you are essentially offloading the cost of lifetime management onto the application developer The lifetime management *is* on the application developer shoulders. It always has and will always be. GC and weakrefs are just conveniences to make this work (much!) easier. There are cases where a GC isn't sufficient. There will always be cases where manual disposal will be necessary. Even if the language gets WeakRefs. When a developer wraps an object in a WeakRef before handing it to observe an event, the developer is making a lifetime management decision. For this and other reasons, I would suggest that it is a horrible idea to use rAF as an example of how to design an API or solve developer problems - especially problems as important as those addressed by weak references. I feel misintrepreted. There is a long way from my I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. and your intrepretation of my post. I shared an idea that hadn't been shared yet on this thread. I didn't say it would solve all problems. I've actually been careful to say that it may not. David [1] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0623.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: Support for IANA time zones
On Sat, Mar 2, 2013 at 5:11 AM, Mark Davis ☕ m...@macchiato.com wrote: It seems we have agreement that the canonicalized IANA names are not good for formatted strings. I like the CLDR solution, but see it as implementation dependent. *Maybe there's just no value in trying to define something in the standard since any implementer can claim that Center, North Dakota and GMT+09:00 are localized representations for some locale.* So, leave it all implementation dependent? I agree. (And you hit on an important point above.) Maybe I'm missing something but ISTM there's an important difference between Center, North Dakota and +09:00 -- DST. I agree it doesn't make sense to solve this problem in the context of formatting, but there wouldn't be an issue if we had a way to set the zone of a Date. In another thread it was claimed that A Date is intended to represent a specific instance in time, irrespective of time zone. But this isn't true at all -- a Date already carries around a timezone tag internally. And if you believe there's no use case for changing a date's timezone, try partitioning a set of Dates by day (or week, month, year, etc.) using a day boundary in a timezone other the current locale's or Zulu. I've come up against this use case more than once, and The solution * sucks*. It involves shipping some subset of the tz db to the client, which is ridiculous -- especially because there's an easy fix... A zone tag already exists, if implicitly, on Dates. What's the harm in making it explicit -- exposing it as a unique symbol? It could be made writable, and a registry of IANA timezones could be exposed as symbols. Per the OP there we still need a mechanism to key the zone symbols -- I don't understand this problem enough to say for sure but the mechanism Mark described seems as good as any. As for how to query for a particular exemplar city and what to do if not present -- this could be reduced to a library problem. This feature belongs in the language. It solves a real problem (as evidenced by the libraries already built). But shipping all or part of the Olsen db is madness -- the client already has it. On Fri, Mar 1, 2013 at 10:33 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: And the time zone names in formatted output when no localized time zone name is available: On Feb 28, 2013, at 15:35 , Norbert Lindenberg wrote: 5) The set of combinations of time zone name and language tag for which localized time zone names are available is implementation dependent. Where no localized time zone name is available, the canonicalized name is used in formatted output. The last one I'm not entirely comfortable with: IANA time zone names can be long and unfamiliar (e.g., America/Indiana/Tell_City), and sometimes people think the wrong representative city was selected (e.g., Shanghai rather than Beijing for China). An alternative might be to prescribe formatting as an offset from UTC. On Feb 28, 2013, at 16:13 , Shawn Steele wrote: For #5 I might prefer falling back to English or something. I don't think UTC offset is a good idea because that doesn't really represent a Timezone very well. (If a meeting gets moved to a following week, that offset might change or be wrong) On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote: This is a problematic. The canonicalized names are very ugly. What we do in CLDR is return the last label, after some modifications (in http://www.unicode.org/repos/cldr/trunk/common/main/root.xml). We don't want to return the raw IDs. I think this needs to be implementation dependent. For example: zone type=Antarctica/DumontDUrville exemplarCityDumont d’Urville/exemplarCity /zone zone type=America/North_Dakota/Center exemplarCityCenter, North Dakota/exemplarCity /zone So I think we should just have #5 be: 5) The set of combinations of time zone name and language tag for which localized time zone names are available is implementation dependent. On Mar 1, 2013, at 9:41 , Phillips, Addison wrote: I think the least surprise would result if the GMT+/- string were used when no local representation is available. While the actually time zone is more specific, most callers are just trying to put a date or time value into their output for human consumption. In most cases, the DST transition rules are unimportant to a specific date value being rendered and the GMT offset is at least somewhat compact. Users are probably more familiar with this presentation and certainly will be happier with it than America/Los_Angeles. It seems we have agreement that the canonicalized IANA names are not good for formatted strings. I like the CLDR solution, but see it as implementation dependent. Maybe there's just no value in trying to define something in the standard since any implementer can claim that Center, North Dakota and GMT+09:00 are localized representations for some locale. So, leave it all implementation
RE: Internationalization: Support for IANA time zones
Re: CLDR names being “better” than tzdb names. I’m uncomfortable using the CLDR names, although perhaps they could be aliases, because other standards use the tzdb names and we have to be able to look up the tzdb names. It might be nice to get more stability for the tzdb names, like aliases or something. Re: UTC vs Tz names Sometimes UTC might be “enough”, or “almost enough”, but there’s a big difference between Pacific Time and UTC-8, because sometimes it might be UTC-7. So just using UTC doesn’t really help formatting (people want something they’re familiar with), and it doesn’t really solve describing the TZ, because at a different time of the year that offset might be different. -Shawn ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: Support for IANA time zones
On Sat, Mar 2, 2013 at 5:11 PM, Shawn Steele shawn.ste...@microsoft.comwrote:
I’m uncomfortable using the CLDR names, although perhaps they could be
aliases, because other standards use the tzdb names and we have to be able
to look up the tzdb names. It might be nice to get more stability for the
tzdb names, like aliases or something.
I'm simply not explaining myself correctly. *The CLDR IDs (long IDs) *ARE*
tzdb IDs.* Let me give you a specific case.
The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used
to have the former as the canonical name (in Zone), but then changed it to
the latter. Here is the current TZDB data:
zone.tab
IN +2232+08822 Asia/Kolkata
asia
Zone Asia/Kolkata 5:53:28 - LMT 1880 # Kolkata
...
backward
Link Asia/Kolkata Asia/Calcutta
Because of the Link, both are valid and equivalent.
CLDR, because we need stability, retains the *former* TZID as the canonical
name. That is the meaning of the first alias in
http://unicode.org/repos/cldr/tags/release-22-1/common/bcp47/timezone.xml such
as in:
type name=inccu alias=*Asia/Calcutta* Asia/Kolkata description=Kolkata,
India/
The short name (name=...) is only used for BCP47 subtags (because of the
ASCII/8-char limit), *not* for communicating with TZDB implementations. Nor
is it used in CLDR for the canonical ID.
Instead Asia/Calcutta is used as the canonical ID. Here are some of the
samples of the localizations.
zone type=Asia/Calcutta
exemplarCityኮልካታ/exemplarCity
/zone
...
zone type=Asia/Calcutta
exemplarCityKolkata/exemplarCity
/zone
...
zone type=Asia/Calcutta
exemplarCityコルカタ/exemplarCity
/zone
and so on. Note that these are all TZIDs.
The only long ID that CLDR adds is one to indicate an unknown/illegal TZID:
zone type=Etc/Unknown
exemplarCity地域不明/exemplarCity
/zone
Is the picture clearer now?
Mark https://plus.google.com/114199149796022210033
*
*
*— Il meglio è l’inimico del bene —*
**
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: Support for IANA time zones
On Mar 2, 2013, at 7:27 , Dean Landolt wrote: I agree it doesn't make sense to solve this problem in the context of formatting, but there wouldn't be an issue if we had a way to set the zone of a Date. In another thread it was claimed that A Date is intended to represent a specific instance in time, irrespective of time zone. But this isn't true at all -- a Date already carries around a timezone tag internally. What makes you believe that? According to the specification, the only data a Date instance has is the [[PrimitiveValue]] internal property, which is a time value, the number of milliseconds since 01 January, 1970 UTC: http://ecma-international.org/ecma-262/5.1/#sec-15.9.6 http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1 The Date constructor and the functions creating Date instances may accept values expressed in the local time zone, but are all specified to calculate a time value in UTC, which then gets stored in the [[PrimitiveValue]]. And if you believe there's no use case for changing a date's timezone, try partitioning a set of Dates by day (or week, month, year, etc.) using a day boundary in a timezone other the current locale's or Zulu. I've come up against this use case more than once, and The solution sucks. It involves shipping some subset of the tz db to the client, which is ridiculous -- especially because there's an easy fix... That's a good use case, and you're right, it's currently not supported. A zone tag already exists, if implicitly, on Dates. What's the harm in making it explicit -- exposing it as a unique symbol? It could be made writable, and a registry of IANA timezones could be exposed as symbols. According to the spec, there is no zone tag. Adding it would make simple operations like comparing the time values of two Date instances a lot more complicated, so I doubt we'd want to do that. I think a better solution would be API that either lets you easily generate a series of Date instances representing midnight (of every day, of every Monday, of every first day of the month, ...) in a specified time zone and calendar, or that lets you convert a Date to field-based time information in a specified time zone and calendar so that you can apply your own criteria. Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: Support for IANA time zones
On Mar 2, 2013, at 8:46 , Mark Davis ☕ wrote:
The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used to
have the former as the canonical name (in Zone), but then changed it to the
latter. Here is the current TZDB data:
zone.tab
IN+2232+08822 Asia/Kolkata
asia
Zone Asia/Kolkata5:53:28 - LMT 1880# Kolkata
...
backward
Link Asia/KolkataAsia/Calcutta
Because of the Link, both are valid and equivalent.
CLDR, because we need stability, retains the former TZID as the canonical
name. That is the meaning of the first alias in
http://unicode.org/repos/cldr/tags/release-22-1/common/bcp47/timezone.xml
such as in:
type name=inccu alias=Asia/Calcutta Asia/Kolkata description=Kolkata,
India/
The short name (name=...) is only used for BCP47 subtags (because of the
ASCII/8-char limit), not for communicating with TZDB implementations. Nor is
it used in CLDR for the canonical ID.
Instead Asia/Calcutta is used as the canonical ID.
That breaks if/when the tz database removes Asia/Calcutta from its Link list
and other systems using IANA names stop supporting (or never start supporting)
that name.
I still think the stability issue should be addressed in the IANA time zone
database itself, not by adopting a IANA-derived alternate registry. Has that
been tried?
Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: What is the status of Weak References?
On 3/2/13 at 3:47 AM, bruan...@gmail.com (David Bruant) wrote: I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. Speaking from ignorance here. One advantage of the resubscribe for every event pattern is that if the events are generated in one process -- an animation process is the example used here -- and a message is sent to the observer in another process, and the observer is slow, the natural outcome will be to drop frames instead of queue up a lot of messages pertaining to events that no longer need to be processed. Cheers - Bill - Bill Frantz| When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: Support for IANA time zones
On Mar 2, 2013, at 8:11 , Shawn Steele wrote: Re: UTC vs Tz names Sometimes UTC might be “enough”, or “almost enough”, but there’s a big difference between Pacific Time and UTC-8, because sometimes it might be UTC-7. So just using UTC doesn’t really help formatting (people want something they’re familiar with), and it doesn’t really solve describing the TZ, because at a different time of the year that offset might be different. Agreed, and if Microsoft or any other implementer wants to provide meaningful localized descriptions of all time zones in all languages, the spec certainly does not prevent that. The question was only whether the spec should describe a fallback to be used when an implementation doesn't have a meaningful localized description, and what that fallback should be. Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: Support for IANA time zones
On Mar 2, 2013, at 10:34 AM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Mar 2, 2013, at 7:27 , Dean Landolt wrote: I agree it doesn't make sense to solve this problem in the context of formatting, but there wouldn't be an issue if we had a way to set the zone of a Date. In another thread it was claimed that A Date is intended to represent a specific instance in time, irrespective of time zone. But this isn't true at all -- a Date already carries around a timezone tag internally. What makes you believe that? According to the specification, the only data a Date instance has is the [[PrimitiveValue]] internal property, which is a time value, the number of milliseconds since 01 January, 1970 UTC: http://ecma-international.org/ecma-262/5.1/#sec-15.9.6 http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1 The Date constructor and the functions creating Date instances may accept values expressed in the local time zone, but are all specified to calculate a time value in UTC, which then gets stored in the [[PrimitiveValue]]. To speak to Dean's implications, many of the Date methods operate on the [[PrimitiveValue]] adjusted for an environmental local offset. Unless specifying obvious UTC versions (e.g. Date.getDay() vs Date.getUTCDay() So, it'd not that the local tz is carried around so much that all these methods rely on the environments. No? And if you believe there's no use case for changing a date's timezone, try partitioning a set of Dates by day (or week, month, year, etc.) using a day boundary in a timezone other the current locale's or Zulu. I've come up against this use case more than once, and The solution sucks. It involves shipping some subset of the tz db to the client, which is ridiculous -- especially because there's an easy fix... That's a good use case, and you're right, it's currently not supported. A zone tag already exists, if implicitly, on Dates. What's the harm in making it explicit -- exposing it as a unique symbol? It could be made writable, and a registry of IANA timezones could be exposed as symbols. According to the spec, there is no zone tag. Adding it would make simple operations like comparing the time values of two Date instances a lot more complicated, so I doubt we'd want to do that. I don't follow how this would make anything more/less complicated if comparison operated on the [[PrimitaveValue]]. Especially if everything just defaults to the way it works now (grab environment's local offset). However, I get not wanting to muck up existing API.. I think a better solution would be API that either lets you easily generate a series of Date instances representing midnight (of every day, of every Monday, of every first day of the month, ...) in a specified time zone and calendar, or that lets you convert a Date to field-based time information in a specified time zone and calendar so that you can apply your own criteria. Agree. Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss Jon Adams Sent from my Refrigerator ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: What is the status of Weak References?
I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. I can't see how this would work in an observer/listener application. The listening object has no way of knowing if it will be deleted when the event occurs, so it cannot decide whether to resubscribe or not. If all references to it were still deleted, it would not go away. It would therefore need a shouldNotResubscribe flag, which must be set when it should be deleted. When the next event occurs it can react and decide not to resubscribe. This means that a listening object still needs a dispose method (to set the shouldNotResubscribe flag), and it also means that it would not be deleted until the next event occurs, which could be in a very long time. Marius On Sat, Mar 2, 2013 at 7:53 PM, Bill Frantz fra...@pwpconsult.com wrote: On 3/2/13 at 3:47 AM, bruan...@gmail.com (David Bruant) wrote: I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. Speaking from ignorance here. One advantage of the resubscribe for every event pattern is that if the events are generated in one process -- an animation process is the example used here -- and a message is sent to the observer in another process, and the observer is slow, the natural outcome will be to drop frames instead of queue up a lot of messages pertaining to events that no longer need to be processed. Cheers - Bill --**--** - Bill Frantz| When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Internationalization: Support for IANA time zones
The Date constructor and the functions creating Date instances may accept values expressed in the local time zone, but are all specified to calculate a time value in UTC, which then gets stored in the [[PrimitiveValue]]. To speak to Dean's implications, many of the Date methods operate on the [[PrimitiveValue]] adjusted for an environmental local offset. Unless specifying obvious UTC versions (e.g. Date.getDay() vs Date.getUTCDay() So, it'd not that the local tz is carried around so much that all these methods rely on the environments. No? That’s correct, but those methods are also misleading and probably not something one would design for the Date class if designing it today. The proposal provides a better means for extracting calendar- and locale-specific field values from a Date object because it allows for calendar variation, local rule variation (start of week, week number, etc.), and for the application of time zone (either explicitly or implicitly). The addition of time zones will allow developers to get not only client-local values, but also to specify a time zone, as many applications require. FWIW, the W3C I18N WG maintains a Note about some of the issues of working with time zones on the Web [1] which I think is helpful when talking about this topic. If you go through the use cases (Norbert, by the way, contributed them to that document), you can see that adding a time zone value to a Date is insufficient for some cases and is overkill for others. I don't think that formally defining time zones would alter the behavior of the getXXX methods, but then the getXXX methods are not sufficient for what you (and I and others) want/need to do anyway. A zone tag already exists, if implicitly, on Dates. What's the harm in making it explicit -- exposing it as a unique symbol? It could be made writable, and a registry of IANA timezones could be exposed as symbols. According to the spec, there is no zone tag. Adding it would make simple operations like comparing the time values of two Date instances a lot more complicated, so I doubt we'd want to do that. I don't follow how this would make anything more/less complicated if comparison operated on the [[PrimitaveValue]]. Especially if everything just defaults to the way it works now (grab environment's local offset). However, I get not wanting to muck up existing API.. If a Date is simply a wrapper around an epochal-time value (what the document I mentioned calls an incremental time), then most time-based operations on the primitive value becomes straightforward (comparison, equality, assignment, etc.). The value has no time zone inherent in it, since it is the same time in UTC everywhere that time is measured. The time zone only matters when extracting calendric field values (day, month, hour, etc.) and, as noted just below, this works better when applied externally. Indeed, it allows the same Date object to be handled in multiple time zones simultaneously, without altering the value itself. It does mean that the time zone must be passed as a separate variable if the time zone is important to the operations that will be performed on time values. I think a better solution would be API that either lets you easily generate a series of Date instances representing midnight (of every day, of every Monday, of every first day of the month, ...) in a specified time zone and calendar, or that lets you convert a Date to field-based time information in a specified time zone and calendar so that you can apply your own criteria. Agree. Addison [1] http://www.w3.org/TR/timezone/ Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: What is the status of Weak References?
I'm still balanced on whether/when/how the one-time listener pattern can be effective, but I feel like it's an interesting idea to discuss. Le 02/03/2013 21:13, Marius Gundersen a écrit : I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. I can't see how this would work in an observer/listener application. The listening object has no way of knowing if it will be deleted when the event occurs, so it cannot decide whether to resubscribe or not. If all references to it were still deleted, it would not go away. It would therefore need a shouldNotResubscribe flag, which must be set when it should be deleted. When the next event occurs it can react and decide not to resubscribe. This means that a listening object still needs a dispose method (to set the shouldNotResubscribe flag) In the weakref case, someone has to keep a strong reference to the listener until it's not needed anymore. The decision to cut this last strong reference is exactly the same decision as deciding when not to re-subscribe. I think the difference is that it might be that the last reference is cut because another object got released and this object got released because another object got released, etc. Unless the entire application is collectable, I think somewhere in the chain, there is an explicit strong reference cut. My point is that being garbage collectable needs an explicit action somewhere. WeakRef is a convenient construct that benefits from a cascading of the explicit action. But there is an explicit action needed somewhere anyway. and it also means that it would not be deleted until the next event occurs, which could be in a very long time. There can be a removeEventListener too. David Marius On Sat, Mar 2, 2013 at 7:53 PM, Bill Frantz fra...@pwpconsult.com mailto:fra...@pwpconsult.com wrote: On 3/2/13 at 3:47 AM, bruan...@gmail.com mailto:bruan...@gmail.com (David Bruant) wrote: I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. Speaking from ignorance here. One advantage of the resubscribe for every event pattern is that if the events are generated in one process -- an animation process is the example used here -- and a message is sent to the observer in another process, and the observer is slow, the natural outcome will be to drop frames instead of queue up a lot of messages pertaining to events that no longer need to be processed. Cheers - Bill - Bill Frantz| When it comes to the world | Periwinkle (408)356-8506 tel:%28408%29356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com http://www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org mailto: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
