short/medium/long/full style for Intl.DateTimeFormat

[zbraniecki]

I'm working on trying to design an alignment between how Intl API works and OS Intl preferences work.

An example of such task is how to incorporate the date/time formatting OS user preferences into DateTimeFormat API.

Currently, we expect users of our API to list the elements of the date/time format as options, or, if none are listed, we take:

• for Intl.DateTimeFormat and Date.prototype.toLocaleString: hour/minute/second/day/month/year as numeric
• for Date.prototype.toLocaleTimeString: hour/minute/second as numeric
• for Date.prototype.toLocaleDateString: day/month/year as numeric

On the other hand, MacOS exposes four styles for date and time: short, medium, long and full.
Windows exposes short/long.

I see two solutions to bind those two APIs:

1. Create OS Intl prefs API that returns Intl API options.

let opts = intlOSPrefs.DateFormat(intlOSPrefs.formatFull);
  --> returns {weekday: 'long', month: 'long', day: 'numeric', year: 'numeric'}
let dtf = new Intl.DateTimeFormat(navigator.locales, opts);
dtf.format(date);

2. Add style option and change how we handle "defaults" in Intl.DateTimeFormat

In this approach, we would use the language in spec similar to one we use for timezones: if user did not specify a timezone, we try to retrieve it from the host OS and we land on the current defaults (all as numeric) only if we cannot get anything from the OS.

date.toLocaleString() == date.toLocaleString(navigator.locales, {
  style: 'medium'
}) == date.toLocaleString(navigator.locales, {
  day: 'numeric',
  month: 'short',
  year: 'numeric'
}); // In MacOS

date.toLocaleDateString(navigator.locales, {
  style: 'long'
}) == date.toLocaleString(navigator.locales, {
  day: 'numeric',
  month: 'long',
  year: 'numeric'
}); // default in MacOS


date.toLocaleDateString(navigator.locales, {
  style: 'full'
}) == date.toLocaleString(navigator.locales, {
  weekday: 'long',
  day: 'numeric',
  month: 'long',
  year: 'numeric'
}); // default in MacOS

That would require adding an additional step in 12.1.2 ToDateTimeOptions as 6.a and 7.a where the implementation could reach to host OS for the preferences and only fallback to the current 6.a and 7.a if those cannot be retrieved.

In this approach, style option would be mutually exclusive with any of the token options.

Opinions? @caridy , @rxaviers , @jungshik, @srl295 ?

[zbraniecki]

(then we could do the same for Number.prototype.toLocaleString and follow the formatting OS preferences there)

[SebastianZ]

3. Add constants referencing the different formats

E.g. Intl.DateTimeFormat could have constants like SHORT, MEDIUM, LONG, FULL.

let dtf = new Intl.DateTimeFormat(navigator.locales, Intl.DateTimeFormat.MEDIUM);
dtf.format(date);

date.toLocaleString() == date.toLocaleString(navigator.locales, Intl.DateTimeFormat.MEDIUM) == date.toLocaleString(navigator.locales, {
  day: 'numeric',
  month: 'short',
  year: 'numeric'
}); // In MacOS

This is a bit shorter than both previous options, but requries toLocaleString() and Intl.DateTimeFormat() to take mixed types of arguments.

Sebastian

[zbraniecki]

Well, the third one is really similar to (2) in that it's implicit - puts the "get the preference from host OS" on the Intl API (much like we do with timeZone now), rather than explicit (1) where we have separate API that retrieves OS preferences.

[zbraniecki]

I separated out the proposal for retrieving user defined preferences from host environment into: #109

So this issue is only about style short/medium/long/full for DateTimeFormat.

[jfkthame]

Mapping preferences retrieved from the OS to values for the year/month/day/hour/minute/second/etc options is not sufficient to fully support the flexibility of OS formatting patterns (if that's a desired goal).

For example, in Mac OS X and Windows, users can customize the order of the components and the separators between them, as well as the format used for each individual components of the date/time. AFAICS, this is not exposed by Intl.DateTimeFormat in any way; the options can be used to control which components are present, and which format is used for each component, but not their order nor any literal separators used between them.

[zbraniecki]

For example, in Mac OS X and Windows, users can customize the order of the components and the separators between them, as well as the format used for each individual components of the date/time. AFAICS, this is not exposed by Intl.DateTimeFormat in any way;

That's not true for windows. See:

• https://bug1308329.bmoattachments.org/attachment.cgi?id=8801351
• https://bug1308329.bmoattachments.org/attachment.cgi?id=8801352

On Mac OS it seems that users can do all of that:

• https://bug1308329.bmoattachments.org/attachment.cgi?id=8801353
• https://bug1308329.bmoattachments.org/attachment.cgi?id=8801354

and I think we could retrieve the pattern from the OS and then operate on it the way we would on a pattern retrieved from CLDR.

[zbraniecki]

but, once again, that's more for #109. Here I'd like to talk about ability to do:

date.toLocaleTimeString(locales, {
  style: 'long'
};

date.toLocaleDateString(locales, {
  style: 'medium'
};

date.toLocaleString(locales, {
  style: 'full',
};

and initially have sane defaults for it irrelevant of the result of #109.

[jfkthame]

That's not true for windows. See:

https://bug1308329.bmoattachments.org/attachment.cgi?id=8801351
https://bug1308329.bmoattachments.org/attachment.cgi?id=8801352

Actually, I think it is; see https://bugzilla.mozilla.org/attachment.cgi?id=8802234.

[zbraniecki]

oh, cool. Didn't find it. Ok, then Windows and MacOS are on par. Still, that's #109 :)

[jfkthame]

Here I'd like to talk about ability to do:

date.toLocaleTimeString(locales, {
  style: 'long'
};

date.toLocaleDateString(locales, {
  style: 'medium'
};

date.toLocaleString(locales, {
  style: 'full',
};

If we go this route, I think we'd want two style-type options for toLocaleString, one each for the date and time portions:

date.toLocaleString(locales, { dateStyle: 'full', timeStyle: 'short' });

And in that case, it'd probably make sense to use the same naming for toLocaleTimeString and toLocaleDateString, rather than a non-specific style option.

[jungshik]

I like introducing {date,time}style = {full, long, medium short}. CLDR has the corresponding styles. It was discussed in v1 spec, but the current way trumped.

[littledan]

@jungshik What led to the current decision? I like the idea of introducing more things that have corresponding CLDR styles.

[zbraniecki]

So, CLDR has styles for date, time, and combinations of date/time: http://www.unicode.org/cldr/charts/30/summary/en.html#1816

I see two ways to expose it:

1. Via one param with 12 options:

style: 'full'|'long'|'medium'|'short'
style: 'date-full'|'date-long'|...
style: 'time-full|'time-long'|...

2. Via two options: date-style and time-style

The problem with this is that not only date and time may have style, but also the pattern that joins those two. It would be awkward to have long date, short time and have to on top of that decide if the pattern that combines them into a single string is long, short or medium.

On the other hand, in the RelativeTimeFormat spec discussion we noticed that the same pattern that joins date and time, can be used to join relative date and time.
So, if the date+time pattern for full is "{0} at {1}" then both can work: "Monday, January 9th at 3:45 pm" and "Tomorrow at 3:45 pm".

If we go for style: "long" in DateTimeFormat, we'll get "Monday, January 9th at 3:45 pm", but I'm not sure how will we build the API for relativedate+time.

Any ideas? Opinions?

[littledan]

First, I'm curious, why are we trying to expose these particular things, and not other things that CLDR exposes, e.g., to take a random one, Hms time format? (Not saying we shouldn't, just wondering what went into it.)

If we do want to expose these combinations, I can think of a few goals in the resulting API:

1. Don't break backwards compatibility for existing users, either in initializing or reading resolvedOptions()
2. Avoid awkward string concatenation/parsing: we already have two structured formats--the options bag and BCP47. A third seems like overkill, and for this, I prefer your second option.

If we go with your option 2, with date-style and time-style, here's a suggestion for how we could square that with a style to preserve:

• The internal slots are [[dateStyle]] and [[timeStyle]]
• The style property as an input in the options bag is used as the "default" value for dateStyle and timeStyle, if either or both are missing
• A style property is created in resolvedOptions if [[dateStyle]] === [[timeStyle]].

What do you think? If we end up permitting things like { timeStyle: "Hms" }, I think this extends pretty cleanly to that--there simply would not be a style property to the resolvedOptions(). Anyway, I don't feel qualified to evaluate the original motivation.

[zbraniecki]

First, I'm curious, why are we trying to expose these particular things, and not other things that CLDR exposes, e.g., to take a random one, Hms time format?

It seems to me that we can start with allowing only descriptive formats and that matches what most OSes expose.

Adding another style like Hms could be done later if need arises.

Your solution looks sane and I can see us doing it. But it doesn't answer the question on how will we work with the date+time joining pattern which can also be full|long|medium|short and potentially work with Intl.RelativeTimeFormat.

I sense that there must be a good solution to that that will allow us solve both - date+time and relativetime+time cases, but I can't see it yet.

[jungshik]

@jungshik What led to the current decision? I like the idea of introducing more things that have corresponding CLDR styles.

Well, both 'style' and 'pattern' were discussed, but in search of the largest common denominator across potential implementations, we ended up defining a rather small subset of patterns available via CLDR with a rather verbose way of specifying them ('year: numeric', 'day: ....', 'hour: ....', 'timeZoneName: short').

Adding more patterns like 'Hms', 'Hm', 'yMMM' , 'yMdjmsvvvv', and so forth was left for the future extension (IIRC). I can think of three ways to do that (now that there's been a convergence toward CLDR as the data source)

1. Add a new 'pattern' option for patterns not covered currently via verbose options
2. a) Make existing options (year, timeZoneName, day, year, etc) to have more values
   b) Add more options if there's currently no option corresponding to LDML 'format speifier'
3. Overload 'style' for both 'convenience names' (long, short, full, medium) and patterns (Hm, yMMMd, jms, Hmsvvvv, etc)

Implementation-wise, one way to handle all three ways ('pattern', current verbose option bags, 'style') is convert them all to a 'pattern' which would be looked up in a given locale data to find the corresponding locale-specific skeleton. (for option bags, that's what v8 does now. It appears that Spidermonkey and JSC do the same).

A proposal put forward here is to overload 'style' with a human-friendly shortcut (full, long, etc) AND 'pattern'. ( third option above).

A couple of questions to answer before deciding what to do:

Which would be best in terms of making DateTimeFormat consistent (in construction and resolvedOptions)?
Which would be easiest and most flexible from the API users' pov?

[zbraniecki]

@caridy , @ericf , @littledan , @rxaviers - opinions?

I'm happy to champion any consensus we can come up with. I mostly care for human-friendly style shortcuts, but I can extend them to cover a list of patterns as @jungshik suggests.

[zbraniecki]

Also, we could do this gradually - get the human-friendly style - full|long|medium|short, and then talk about adding patterns.
Unless anyone has a current use case for the pattern styles (Hm, yMMMd etc.)

[zbraniecki]

This proposal has received Stage 1 at today's TC39 meeting.

[zbraniecki]

I asked the committee about style: "date-short" vs dateStyle: "short".

The only feedback was that the latter looks more like CSS which may be good, but it seems that there are no strong feelings one way or another and it's up to us to decide.

[rxaviers]

I'm happy to champion any consensus we can come up with. I mostly care for human-friendly style shortcuts

👍 on adding these human-friendly styles. options.style seems a good name to me.

What should happen if style and any verbose field is mutually present, e.g., {style: X, year: Y}. Should an error be thrown?

The problem with this is that not only date and time may have style, but also the pattern that joins those two. It would be awkward to have long date, short time and have to on top of that decide if the pattern that combines them into a single string is long, short or medium.

@zbraniecki, the combination pattern can be deduced from the date and time lengths according to CLDR (UTS#35) http://www.unicode.org/reports/tr35/tr35-dates.html#dateTimeFormat.

I asked the committee about style: "date-short" vs dateStyle: "short".

One benefit of overriding style with style: "date-short" is that we have less mutual exclusive options. For example, using dateStyle, timeStyle, and style would require additional checks to assert they are not being mutually used (in addition to them vs. the verbose options such as year, month, etc).

Via one param with 12 options.

@zbraniecki, in addition to these 12 options, there are the non-uniform datetimes, e.g.,date-short x (time-medium, time-long, time-full) + date-medium x (...) + .... At least, this seems expected according to ICU and CLDR (UTS#35) http://www.unicode.org/reports/tr35/tr35-dates.html#dateTimeFormat.

---

but I can extend them to cover a list of patterns as @jungshik suggests.

👍 too... CLDR calls them skeletons, which contains "only field information and in a canonical order". [1]

I personally like the brevity of skeletons compared to the verbose options year, month, etc. For example:

let fmt = new Intl.DateTimeFormat(locales, {style: "yMMMdjm"});

let equivalentFmt = new Intl.DateTimeFormat(locales, {
  year: 'numeric',
  month: 'short',
  day: 'numeric',
  hour: 'numeric',
  minute: 'numeric'
});

2. a) Make existing options (year, timeZoneName, day, year, etc) to have more values
   b) Add more options if there's currently no option corresponding to LDML 'format speifier'

I agree with @jungshik's point.

3. Overload 'style' for both 'convenience names' (long, short, full, medium) and patterns (Hm, yMMMd, jms, Hmsvvvv, etc)

I see two benefits of overriding options.style:

1. Otherwise, we would have to discuss its name: options.pattern or options.skeleton (to be in line with CLDR?) or something else? 😊 Note CLDR refers to pattern as the format that a skeleton maps to.
2. Less mutual exclusive options like mentioned above.

let dtf = new Intl.DateTimeFormat(navigator.locales, Intl.DateTimeFormat.MEDIUM);

@SebastianZ the downside of this approach is that it makes it hard to combine it with other options such as timeZone. For clarity, if we had consts, I would make them strings, not objects.

---

1: Skeleton is a more flexible formatting mechanism than the predefined list of short, medium, long, full formats.

The availableFormats element and its subelements provide a more flexible formatting mechanism than the predefined list of patterns represented by dateFormatLength, timeFormatLength, and dateTimeFormatLength. Instead, there is an open-ended list of patterns (represented by dateFormatItem elements as well as the predefined patterns mentioned above) that can be matched against a requested set of calendar fields and field lengths. Software can look through the list and find the pattern that best matches the original request, based on the desired calendar fields and lengths. For example, the full month and year may be needed for a calendar application; the request is MMMMyyyy, but the best match may be "y MMMM" or even "G yy MMMM", depending on the locale and calendar.

The id attribute is a so-called "skeleton", containing only field information, and in a canonical order.

http://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems

[zbraniecki]

@zbraniecki, the combination pattern can be deduced from the date and time lengths according to CLDR (UTS#35) http://www.unicode.org/reports/tr35/tr35-dates.html#dateTimeFormat.

That's cool!
That means that the decision between date-style+time-style vs style is purely about whether we want to allow people to define different date and time styles in one formatter (say, short time but long date).

Otherwise, we would have to discuss its name: options.pattern or options.skeleton (to be in line with CLDR?) or something else?

Internally at this point, we still will introduce an option.pattern because we need to pass the OS date/time pattern to the mozIntl.DateTimeFormat.
So depending on how we'll solve the host env. preferences (implictly within the formatter, or explicitly as a separate API, and then will we try to pass everything via BCP47, or as options) we will need to figure out if we need options.pattern.

👍 too... CLDR calls them skeletons, which contains "only field information and in a canonical order". [1]

I like the skeletons, I'm just a bit worried about the scope of the proposal. Adding just short/medium/long/full will allow us to get something done and we can always extend it to support a selected list of skeletons later.

[rxaviers]

That means that the decision between date-style+time-style vs style is purely about whether we want to allow people to define different date and time styles in one formatter (say, short time but long date).

That only means we don't need to ask user to provide the length of the "gluer" format. :) I believe something like {style: 'date-short-time-long'} could still be an option?

Internally at this point, we still will introduce an option.pattern because we need to pass the OS date/time pattern to the mozIntl.DateTimeFormat.

... and by pattern you mean pattern right? For example, the "yMd" skeleton maps to the following patterns in these different locales:

locale	pattern
en	"M/d/y"
es	"d/M/y"
de	"d.M.y"

I believe that internally it would be ok. I want to emphasized that a possible options.pattern doesn't get exposed to users, because it can't be used for localization and it would lead into bad i18n practices. The possible options.style discussed here and the existing verbose options are still the right ways for users to provide such input.

[rxaviers]

I like the skeletons, I'm just a bit worried about the scope of the proposal. Adding just short/medium/long/full will allow us to get something done and we can always extend it to support a selected list of skeletons later.

Ok. No strong opinion from my side on this roadmap.

[caridy]

style seems like a half-baked solution compared with skeletons, we can see it as a more human friendly styling mechanism but one that is crippled since it does not allow you to do more advanced things. That might be ok, but at the same time, I think skeletons are almost ubiquitous for any internationalization platform, that we probably should lean toward that solution.

[zbraniecki]

style seems like a half-baked solution compared with skeletons, we can see it as a more human friendly styling mechanism but one that is crippled since it does not allow you to do more advanced things.

One more thing is that human friendly styles is what host environments speak. So to enable developers to be able to say "style this date the way user wants a full date to be styles", we need this concept.

[zbraniecki]

See all the screenshots from platforms in this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1308329 for reference of what users are able to manually define.

[jungshik]

Sorry for mixing up 'pattern' and 'skeleton' in my previous comment. From now on, I'll adhere to the CLDR terminology. skeleton is just a list of field specifiers (e.g. yMd, jmsv, MMMd) and locale-specific patterns can be derived from a given skeleton based on the locale data. (the pattern for yMd can be y. M. d. in 'ko', M/d/y for en-US and d/M/y for fr, en-GB, etc). And, some users may want to make up a pattern independent of a skeleton/locale (e.g, 'yyyy-MM-dd')

Otherwise, we would have to discuss its name: options.pattern or options.skeleton (to be in line with CLDR?) or something else?

Internally at this point, we still will introduce an option.pattern because we need to pass the OS date/time pattern to the mozIntl.DateTimeFormat.
So depending on how we'll solve the host env. preferences (implictly within the formatter, or explicitly as a separate API, and then will we try to pass everything via BCP47, or as options) we will need to figure out if we need options.pattern.

By options.pattern, which do you mean 'skeleton' or 'pattern' in the CLDR sense? It looks like you mean 'pattern' in the CLDR sense, but I think 'options.skeleton' (for skeleton in the CLDR sense) is a lot more useful than 'options.pattern'. There can be a use-case for 'options.pattern' (when a fixed format is required regardless of locale), but this use-case is rather limited than 'skeleton'.

Internally, options.style, options.skeleton and current verbose option bags (for year, month, day, hour, etc) should be resolved to a 'skeleton' with a well-defined priority (and conflict-resolution recipes) among them. And, this resolved skeleton can be a part of resolvedOptions as a succinct representation of date-time format (other than calendar, numberingSystem, timeZone).

Unless options.pattern is introduced as well, we can stop here in terms of what's available via resolvedOptions.

One more thing is that human friendly styles is what host environments speak. So to enable developers to be able to say "style this date the way user wants a full date to be styles", we need this concept.

I like the idea of adding a 'human-friendly' and 'succinct/less verbose' way to specify a format, but
I have a reservation about tying 'full, medium, short, long' styles to the host environment preference.

[zbraniecki]

By options.pattern, which do you mean 'skeleton' or 'pattern' in the CLDR sense? It looks like you mean 'pattern' in the CLDR sense

Yes, I mean pattern in CLDR sense. That's exactly what Windows, Mac, Android and Linux can provide me.

I like the idea of adding a 'human-friendly' and 'succinct/less verbose' way to specify a format, but
I have a reservation about tying 'full, medium, short, long' styles to the host environment preference.

I don't see how you can advance the web as a platform without closing this gap. Currently, every native platform will allow you to format date and time according to user preferences.
Since we're trying to use ECMA402 API for Firefox UI, and we need Firefox UI to be able to follow user preferences, I need this feature badly.

I understand if we'll decide not to expose it to the Web, but I believe that over time there will be more platforms that will want to use JS based Intl API and will want this feature (Electron?).

For that reason, I believe that having style with those names will allow those platforms to easily tie into OS preferences, while for the Web it will just mean that users can easily get the simplest solution (most users of DateTimeFormat will not dwell into what's a skeleton and just want a long date).

[zbraniecki]

@caridy https://rawgit.com/zbraniecki/proposal-ecma402-datetime-style/master/out/ this ?

[caridy]

thanks @zbraniecki, let's transfer that repo to TC39 as well.

[FrankYFTang]

Should we close this issue since we already have dateStyle and timeStyle proposal reach stage 3?

[sffc]

We can close this when the corresponding proposal reaches Stage 4 and is merged. This issue has the tag "active proposal".

[zbraniecki]

The number of remaining active items is as follows:

• Date-time field widths not set for PartitionDateTimePattern proposal-intl-datetime-style#45 which is addressed in Improve handling of date/time style field widths. proposal-intl-datetime-style#48
• Use TypeError instead of RangeError when mixing date-/timeStyle with other date/time options proposal-intl-datetime-style#46
• Decide on the resolvedOptions for styles proposal-intl-datetime-style#49

The first one is an editorial bug that I'm working on.
The latter two are decisions for us to make and I'd like to ask for your input.

Assuming we can come up with a consensus on the latter two over the upcoming ECMA402 call, I plan to propose this for Stage 4 advancement soon.

[zbraniecki]

dateStyle/timeStyle proposal has been approved for Stage 4 at today's TC39 meeting!

[chiqui3d]

Why do you like to make such a big mess? I think it would be a little easier to kind of

(new Date())->format('d-m-Y'); // 24-07-2020

new Intl.DateTimeFormat("es",{ISO:'d-m-Y'}).format(Date.now()); // 24-07-2020

I apologize if this doesn't go here, but I don't know where I can make a request or show my disagreement with Javascript and the dates.

[srl295]

@chiqui3d in regards to:

(new Date())->format('d-m-Y'); // 24/07/2020
new Intl.DateTimeFormat("es",{ISO:'d-m-Y'}).format(Date.now()); // 24/07/2020

It doesn't go here because it goes here: #190 - please follow up there, thanks!

[zbraniecki]

I apologize if this doesn't go here, but I don't know where I can make a request or show my disagreement with Javascript and the dates.

What you're suggesting is not internationalization date pattern. ISO is universal and you can format Date to it without Intl.

[chiqui3d]

That's how I do it in PHP, it's simple and easy, in Javascript I don't understand how it's so complicated.

https://www.php.net/manual/en/function.date.php
https://www.php.net/manual/en/datetime.format.php#refsect1-datetime.format-examples

[FrankYFTang]

That's how I do it in PHP, it's simple and easy, in Javascript I don't understand how it's so complicated.

https://www.php.net/manual/en/function.date.php
https://www.php.net/manual/en/datetime.format.php#refsect1-datetime.format-examples

That means, if your caller need to support 240 locales, the engineer need to code 240 patterns, one for each locale, in order to use your system to support that 240 locales properly. While it might be easy for you, or any engineer to figure out the first 2-5 patterns, it will be hard to find out the 6th to 240th.

[srl295]

(new Date())->format('d-m-Y'); // 24/07/2020

Looking at this again: why are the hyphens there? Just have "dmY" => 24/07/2020 and it's just a skeleton, as discussed earlier. (dmY=mYd etc; order does not matter)

[srl295]

That's how I do it in PHP, it's simple and easy, in Javascript I don't understand how it's so complicated.

https://www.php.net/manual/en/function.date.php

https://www.php.net/manual/en/datetime.format.php#refsect1-datetime.format-examples

The php docs say "This method does not use locales. All output is in English." So as frank said, this has little to do with internationalization.

[chiqui3d]

I set the wrong example, it should be // 24-07-2020

But if it can't be, then nothing will continue to use third party Javascript libraries like

https://date-fns.org/v2.15.0/docs/format

var result = format(Date.now(), 'dd-MM-yyyy')
//=> 24-07-2020

https://momentjs.com/

moment().format('DD-MM-YYYY'); // 24-07-2020

Everyone has their differences, so I'm looking for something native.

[FrankYFTang]

I set the wrong example, it should be // 24-07-2020

But if it can't be, then nothing will continue to use third party Javascript libraries like

https://date-fns.org/v2.15.0/docs/format

var result = format(Date.now(), 'dd-MM-yyyy')
//=> 24-07-2020

https://momentjs.com/

moment().format('DD-MM-YYYY'); // 24-07-2020

Everyone has their differences, so I'm looking for something native.

What you propose, is to let the library to allow the programmer to control exactly what the pattern is. The problem is, the pattern is different, depending on each locale, so, by providing such "low level" API, it encourage the developer to program their code based on lower level construct, and make the software much harder to extend to locales/countries, because, under such paradigm, the developer need to know the pattern for ALL the pattern of the locales they need to support, therefore, it push the responsibility of figuring out that cultural information to the developers, instead of depending on what the cultural information the library collected from many linguists. For example, could you name the date patterns of the top 80 locales your software are going to support? and how long do you think it will take for you, personally, not some magic guru you believe your boss is going to hire to help you, to find these 80 patterns? I am sure you can easily list the first 3-7 (say US, UK, Canada, AU, NZ, and maybe even France and Germany). But it will be very difficult after that, right? How about in Thailand, China, Japan, Armenia? If you think it is easy to figure out, try some of them I listed above and tell me how long it take for you to be sure and how many Unit test you need to write to verify that.