<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 2, 2013 at 5:11 AM, Mark Davis ☕ <span dir="ltr"><<a href="mailto:mark@macchiato.com" target="_blank">mark@macchiato.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div style="font-family:'times new roman',serif">> <span style="font-size:10px;font-family:arial,sans-serif">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. <i><b>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.</b></i> So, leave it all implementation dependent?</span></div>



<div style="font-size:10px;font-family:arial,sans-serif"></div><div style="font-size:10px;font-family:arial,sans-serif"><br></div></div><div style="font-size:10px;font-family:arial,sans-serif">
<div>​I agree.​ (And you hit on an important point above.)</div></div></div></blockquote><div><br><br></div><div>Maybe I'm missing something but ISTM there's an important difference between "Center, North Dakota" and "+09:00" -- DST.<br>


<br></div><div>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 <span class="">Date</span> 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 <b>sucks</b>. It involves shipping some subset of the tz db to the client, which is ridiculous -- especially because there's an easy fix...<br>

<br>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.<br>

<br></div><div>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.<br></div><div>

 </div><div class="gmail_extra"> <br><br><div class="gmail_quote">On Fri, Mar 1, 2013 at 10:33 PM, Norbert Lindenberg <span dir="ltr"><<a href="mailto:ecmascript@lindenbergsoftware.com" target="_blank">ecmascript@lindenbergsoftware.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And the time zone names in formatted output when no localized time zone name is available:<br>
<div><br>
On Feb 28, 2013, at 15:35 , Norbert Lindenberg wrote:<br>
<br>
> 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.<br>




><br>
> 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.<br>




<br>
<br>
</div><div>On Feb 28, 2013, at 16:13 , Shawn Steele wrote:<br>
<br>
> 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)<br>




<br>
</div><div>On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:<br>
<br>
</div><div>> This is a problematic. The canonicalized names are very ugly. What we do in CLDR is return the last label, after some modifications (in <a href="http://www.unicode.org/repos/cldr/trunk/common/main/root.xml" target="_blank">http://www.unicode.org/repos/cldr/trunk/common/main/root.xml</a>). We don't want to return the raw IDs. I think this needs to be implementation dependent.<br>




><br>
> For example:<br>
><br>
> <zone type="Antarctica/DumontDUrville"><br>
> <exemplarCity>Dumont d’Urville</exemplarCity><br>
> </zone><br>
> <zone type="America/North_Dakota/Center"><br>
> <exemplarCity>Center, North Dakota</exemplarCity><br>
> </zone><br>
><br>
> So I think we should just have #5 be:<br>
><br>
</div><div>> 5) The set of combinations of time zone name and language tag for which localized time zone names are available is implementation dependent.<br>
<br>
</div><div>On Mar 1, 2013, at 9:41 , Phillips, Addison wrote:<br>
<br>
> 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".<br>




<br>
</div>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?<br>




<span><font color="#888888"><br>
Norbert<br>
</font></span><div><div><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</div></div></blockquote></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div></div>