Date.prototype.format
On Fri, May 27, 2011 at 11:48 AM, Marc Harter <wavded at gmail.com> wrote:
This may of been thrown though the ringer already but I thought I'd ask.
blog.stevenlevithan.com/archives/date-time-format
This is some awesome work on date formatting. What do we think about having a native Date Format implementation in es.next? Complications? Seems like this a very commonly needed option. Especially w/ SSJS now getting more popular.
Note that it is rarely useful to format with a fixed pattern, because different locales have different norms for ordering of the fields, separators, etc.
On Fri, May 27, 2011 at 11:08 AM, John Tamplin <jat at google.com> wrote:
On Fri, May 27, 2011 at 11:48 AM, Marc Harter <wavded at gmail.com> wrote:
This may of been thrown though the ringer already but I thought I'd ask.
blog.stevenlevithan.com/archives/date-time-format
This is some awesome work on date formatting. What do we think about having a native Date Format implementation in es.next? Complications? Seems like this a very commonly needed option. Especially w/ SSJS now getting more popular.
Thanks!
Note that it is rarely useful to format with a fixed pattern, because different locales have different norms for ordering of the fields, separators, etc.
By fixed pattern do you mean like d.format('YY/mm/dd')? If so, doesn't that allow for more expressive power?
On Fri, May 27, 2011 at 12:21 PM, Marc Harter <wavded at gmail.com> wrote:
Note that it is rarely useful to format with a fixed pattern, because different locales have different norms for ordering of the fields, separators, etc.
By fixed pattern do you mean like d.format('YY/mm/dd')? If so, doesn't that allow for more expressive power?
To illustrate the problem, consider formatting a date next week with "M/d/y", giving 6/1/2011. US readers will understand that readily. However, if a European user sees that, they will interpret it as if it were "d/M/y", and they will think it is in January. Also, many locales have different separators for the portions of the date, or insert additional words in the longer formats, which won't be present if you just used a fixed format pattern.
Instead, you should use a skeleton pattern of "Mdy" saying that you want a format with numeric values for month day and year. Then, you get the proper format for the locale your user is running your app in. Even better, though more restrictive, is to use a predefined format where experts in each locale have said this is a good "short" date format for that locale, since there are different conventions.
For examples from CLDR, see:
unicode.org/cldr/trac/browser/tags/release-2-0/common/main/en.xml#L1259
unicode.org/cldr/trac/browser/tags/release-2-0/common/main/en_GB.xml#L57
unicode.org/cldr/trac/browser/tags/release-2-0/common/main/zh.xml#L1166
unicode.org/cldr/trac/browser/tags/release-2-0/common/main/en.xml#L1217
unicode.org/cldr/trac/browser/tags/release-2-0/common/main/zh.xml#L1123
Certainly, there are cases where you do want a fixed format (and in fact you don't want localized names, but rather the English month/day names), such as when formatting an RFC2822 date, and in those cases you do want to be able to use a fixed format string.
On Fri, May 27, 2011 at 4:59 PM, Adam Shannon <adam at ashannon.us> wrote:
I like the idea of putting .format() on the Date; it would allow for quick and easy access to a handy formatter. However, would it make more sense to use the set that php uses to format dates?0 I would assume that developers would be more familiar with that.
Since that isn't the format used in CLDR, you would have to translate the localized formats to that. Also, you can't properly localize date formats for all the locales given that, since for example it doesn't support the concept of standalone vs non-standalone month names.
This may of been thrown though the ringer already but I thought I'd ask.
blog.stevenlevithan.com/archives/date-time-format
This is some awesome work on date formatting. What do we think about having a native Date Format implementation in es.next? Complications? Seems like this a very commonly needed option. Especially w/ SSJS now getting more popular.