ecma402
ecma402 copied to clipboard
tc39
First day of the week -- Intl.getCalendarInfo()
It seems like there's no way with the current specifications to know the first day of the week for a given locale.
I understand ISO 8601 does consider Monday as the first working day: maybe this is the reason. However there are some locales (AFAIK Canada, U.S. and Mexico) where Sunday should be shown as first day of the week - eg in calendars or date pickers. Is there any plan to make available this information?
The first day of the week drastically varies between Saturday, Sunday, or Monday (or even Friday) between different locales: https://github.com/unicode-cldr/cldr-core/blob/master/supplemental/weekData.json#L61. So, it's definitively wrong to assume it's always Monday.
On jQuery UI datepicker, this information is pulled from CLDR https://github.com/jquery/jquery-ui/blob/datepicker-globalize-1.x/ui/calendar.js#L187 (which in turn, uses https://github.com/rxaviers/cldrjs/blob/master/src/supplemental/main.js#L22-L25).
Having said that, I agree it's useful having this information available for implementations like datepicker. Although, I leave it open for discussion on how this information should be exposed.
Obviously we don't use such information today as part of the current spec, but we have been talking about exposing more low-level abstract operations and data in issue #5, maybe exposing low level data like this falls into the same bucket.
Yes, CLDR has this information. Another related information that might be useful on calendars implementations is the first day of the year.
It has it here: http://www.unicode.org/repos/cldr/trunk/common/supplemental/supplementalData.xml
Note tr35 specifically:
The day indicated by firstDay is the one that should be shown as the first day of the week in a calendar view. This is not necessarily the same as the first day after the weekend (or the first work day of the week), which should be determined from the weekend information. Currently, day-of-week numbering is based on firstDay (that is, day 1 is the day specified by firstDay), but in the future we may add a way to specify this separately.
What is meant by the weekend varies from country to country. It is typically when most non-retail businesses are closed. The time should not be specified unless it is a well-recognized part of the day. The weekendStart day defaults to "sat", and weekendEnd day defaults to "sun". For more information, see Dates and Date Ranges.
So two concepts: "the weekend" and "first day of week for calendar display".
Now, the question is where do we want to display it. One idea is to use Intl.Locale API (#46) to get a list of information about the given locale. Things like:
- firstDayOfTheWeek
- weekendStarts, weekendEnds
- direction (ltr/rtl)
- calendar type
and maybe one day:
- ordered list of currencies
- ordered list of timezones
- ordered list of scripts
This stuff we could get from supplemental CLDR data, and might help pushing those options to the top of selection lists for a selected locale.
But the basics are already available and I was already planning providing getDirection(locale) function. Maybe instead it should be Intl.Locale.getLocaleInfo(locale) ?
I like the idea of getLocaleInfo, easy to expand later without adding dozens of methods.
Having dozens of methods should be fine (equivalent to having dozens of exports in a module). That's probably easy to detect and polyfill.
@caridy - Does it mean you'd prefer to keep methods like Intl.Locale.getDirection, Intl.Locale.getFirstDayOfTheWeek etc?
My concern here is how it'll scale. I don't know prior examples of APIs that define new function for each bit of data.
It is not a matter of scale (this is a finite number of apis), it is the fact that users will probably need one at a time, not a bulk. But I do agree that we should look into precedents for this, maybe a DOM api, certainly I don't know any JS api that provides that kind of granularity.
Latest version of https://github.com/tc39/ecma402/issues/46 has ability to do:
Intl.resolveLocaleInfo('en-US', {firstDay: true}); // {'locale': 'en-US', 'firstDay': 0}
Intl.resolveLocaleInfo('fr', {firstDay: true}); // {'locale': 'fr', 'firstDay': 1}
For Gecko internal use, I landed an API mozIntl.getCalendarInfo which works like this:
mozIntl.getCalendarInfo('en-US') === {
firstDayOfWeek: 1,
minDays: 1,
weekendStart: 7,
weekendEnd: 1,
calendar: "gregory",
locale: "en-US"
};
I'll be happy to transition away from it toward any standard solution we may come up with for ECMA402.
@zbraniecki To clarify, presumably the string passed in can be a whole locale, with BCP 47 u options, right?
API shape bikeshedding:
- Minor: Should this be a (static) method on DateTimeFormat?
- Major: What if you just put this extra information in the response to Intl.DateTimeFormat().resolvedOptions()? What would be the downside?
Major: What if you just put this extra information in the response to Intl.DateTimeFormat().resolvedOptions()? What would be the downside?
Would it be a getter on the new object created every time? Or a new member with a new object created every time? I don't think resolvedOptions is an expensive operation, nor many people use it, but certainly don't want to make it slower, specially because we will have to cross the bridge to grab that data.
I guess you're right; even if it wouldn't be a performance killer here, we couldn't expose everything ih CLDR about every locale in resolvedOptions.
What if it were a new instance method on DateTimeFormat instances (which are already a thing that has a calendar based on various options)? This would let you get information about the same calendar that you're formatting dates with, as opposed to needing to pass the locale in a different form that might not match up.
My current idea on how to add a getter for the first day of the week is to add support for the fw keyword to Intl.Locale in conjunction with #409 that lets you get the default value for that keyword.
I'm not sure how to get weekend data with this approach, though, because I don't see keys for that in the locale string.
The icu/sources/data/lang/en.txt contains:
en.Keys.fw={"First day of week"}
en.Types.fw= {
fri{"First Day of Week Is Friday"}
mon{"First Day of Week Is Monday"}
sat{"First Day of Week Is Saturday"}
sun{"First Day of Week Is Sunday"}
thu{"First Day of Week Is Thursday"}
tue{"First Day of Week Is Tuesday"}
wed{"First Day of Week Is Wednesday"}
}
Please provide means in EcmaScript.Intl to extract these strings, if this was not considered so far.
Other langs do not have fw yet, but this might be due the fact that EcmaScript.Intl does not expose it.
@dilyanpalauzov I think getting locale-informed strings is more in the domain of Intl.DisplayNames than this issue.
I intend to work on this issue by proposing https://github.com/FrankYFTang/proposal-intl-locale-info/
I agree with @ryzokuken this feature request has nothing to do with "USER" preference.