First day of the week -- Intl.getCalendarInfo()

[gpbl]

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?

[rxaviers]

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.

[caridy]

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.

[zbraniecki]

It would be also helpful for all calendar UIs.

[caridy]

Ok, let's find a champion for this feature, I can help with the spec.

[zbraniecki]

Do we also want weekendStarts and weekendEnds here? Seems relevant.

[caridy]

@zbraniecki can you double check that we have that information in CLDR?

[rxaviers]

Yes, CLDR has this information. Another related information that might be useful on calendars implementations is the first day of the year.

[zbraniecki]

It has it here: http://www.unicode.org/repos/cldr/trunk/common/supplemental/supplementalData.xml

[caridy]

great!

[srl295]

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

[zbraniecki]

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) ?

[realityking]

I like the idea of getLocaleInfo, easy to expand later without adding dozens of methods.

[caridy]

Having dozens of methods should be fine (equivalent to having dozens of exports in a module). That's probably easy to detect and polyfill.

[zbraniecki]

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

[caridy]

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.

[zbraniecki]

Latest version of #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}

[zbraniecki]

I suggest we close this issue and continue discussion in issue #46.

[zbraniecki]

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.

[littledan]

@zbraniecki To clarify, presumably the string passed in can be a whole locale, with BCP 47 u options, right?

[zbraniecki]

yes :)

[littledan]

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?

[caridy]

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.

[littledan]

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.

[caridy]

@littledan I like that better :)

[FrankYFTang]

I intend to work on this issue by proposing https://github.com/FrankYFTang/proposal-intl-locale-info/

[ryzokuken]

Same as #205, can we atleast drop "user preferences" label?

[FrankYFTang]

I agree with @ryzokuken this feature request has nothing to do with "USER" preference.

[sffc]

I dropped the label, but I do actually feel that this is related to user preferences, because a user could in the future override the locale default using the -u-fw- extension keyword, for example.

[ryzokuken]

@sffc is the fw extension keyword currently supported? If not, then that deserves an issue of its own, right? 😇

[sffc]

@sffc is the fw extension keyword currently supported? If not, then that deserves an issue of its own, right? 😇

I was thinking that this one would be the issue to track "fully supporting" the first day of the week, but since Intl Locale Info is proceeding without support for -u-fw, then yes, we should open a new issue. The issue should be generally about adding additional Unicode extension keywords.

[ryzokuken]

@sffc perfect, I will create one right now.

[ryzokuken]

@sffc check out #580

[Yegorich555]

Hi there, do we have any movements today ?

[sffc]

In the latest V8, you can do

new Intl.Locale(navigator.language).weekInfo
// {firstDay: 7, weekend: Array(2), minimalDays: 1}

However, this is not yet stable and is likely to change into a function call; see tc39/proposal-intl-locale-info#62