Normative: Add quarter option #345
Conversation
|
Usage: let d = new Date();
var dtf = new Intl.DateTimeFormat("en", {year: "numeric", quarter: "short"});
dtf.format(d); // "Q2 2019"
dtf.formatToParts(d);
// [{type: "quarter", value: "Q2"},
// {type: "literal", value: " "},
// {type: "year", value: "2019"}]
dtf = new Intl.DateTimeFormat("en", {year: "numeric", quarter: "long"});
dtf.format(d); // "2nd quarter 2019"
dtf.formatToParts(d);
// [{type: "quarter", value: "2nd quarter"},
// {type: "literal", value: " "},
// {type: "year", value: "2019"}]
dtf = new Intl.DateTimeFormat("zh-Hant", {year: "numeric", quarter: "short"});
dtf.format(d); // "2019年第2季"
dtf.formatToParts(d);
// [{type: "year", value: "2019"},
// {type: "literal", value: "年"},
// {type: "quarter", value: "第2季"}] |
FrankYFTang
changed the title
FrankYFTang
added
c: datetime
|
LGTM; let's discuss in the next meeting to seek consensus. |
|
LGTM as well. Is the idea here to pursue this feature as a one-off, or did you have more Intl.DateTimeFormat feature proposals as well? |
That is the question I am not sure. There are 3 thing (or 4 if we count the relativeYear / yearName you proposed) we should address, all of them are kind of independent from each other: I wonder should I file one by one as PR or group them together as a proposal (see https://github.com/FrankYFTang/proposal-intl-datetimeformat-more-options/blob/master/README.md ). Should I also include the "yearName" into such proposal? |
|
How about I just file all the changes one by one as PR here so we will have a sense of what the changes look like. And if we all feel it need to be group into a bigger proposal I can just merge those changes there. |
|
v8 prototype in https://chromium-review.googlesource.com/c/v8/v8/+/1621445 |
FrankYFTang
changed the title
|
We have discussed this PR in Jun 5 2019 TC39 and decided this is small enough and align with pre-existing API already and therefore does not need to form a staged proposal but do require consensus with in ECMA402 committee + tests in test262 + 1 js engine implementation and no concern from other js implementation to land into ECMC402 as stage 4. |
|
Initial set of tests in tc39/test262#2194 |
|
Questions from the Intl meeting:
We need to find a reasonable answer to these questions before we achieve consensus for the PR |
Quarter, regardless which calendar system we are using, is defined as (month / 3) in zero-based quarter and zero-based month I will make a spec change to clarify that quarter is calculated from month / 3.
Other periods are not being considered here, but neither will conflict with this proposal. For example, if there are strong demand, we can propose to add to format "decade" (e.g "80") , "century" ("21st century"), "semester" ("first semester"), or "trimester" and won't conflict with this. The scope of this PR is only tight to a frequently use period in the modern world:
It is not intend to be a general abstract period that cover other concept in different calendar system. |
|
API behave in non gregorian calendars is now fully specified by 6c60ab7 |
quarter option- see tc39/ecma402#345 dayPeriod option- see tc39/ecma402#346 fractionalSecondDigits option- see tc39/ecma402#347 2019-6-5 TC39 presentation- http://shorturl.at/mtB12 test262: tc39/test262#2194 I2I: http://shorturl.at/beCNV (for quarter) I2I: http://shorturl.at/bekrZ (for dayPeriod) I2I: http://shorturl.at/flwF5 (for fractionalSecondDigits) Bug: v8:9282,v8:9283,v8:9284 Change-Id: I99f4c0f861507c7451497b735a276780bb8aead6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621445 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#62041}
|
So we got feedback that in the UK there are 'financial years' which start April 1st, and companies use those quarters in their reporting, and so 'quarters' need to be calculated from a different start date than the calendar.
Yes, but in the UK, here is a "1st Quarter" report that ends July 1st: If the primary use for Quarters is financial, I think this may need some more thought. I know this is a longstanding ICU/CLDR and Java feature. But if it is not sufficient for a large number of cases, then we should probably rethink whether this feature should be simply named |
|
I've opened CLDR-13109 to discuss these questions on the CLDR side. edit it turns out that some of these questions have been raised before (by myself and others). No concrete consensus. |
OK, but for say Hebrew calendar in a leap year, there are 13 months. so would that result in "5th Quarter"? (Note: There's no CLDR data for edit actually, it's 0-11 in non-leap, 0-12 in leap years. Still end up with a 5th 'quarter'. (test code and rer-inspection of ICU source) |
|
FYI: In the Netherlands we have a normal fiscal year (boekjaar; 1 Jan – 31 Dec), but also a "broken" fiscal year, which can start on 1 Apr, 1 Jul, whatever makes the most sense for an organisation. In addition a fiscal year might be shorter than 1 year but also longer, to a maximum of 24 months minus 1 day. |
| @@ -281,7 +286,10 @@ <h1>PartitionDateTimePattern ( _dateTimeFormat_, _x_ )</h1> | |||
| 1. Let _p_ be the substring of _pattern_ from position _beginIndex_, exclusive, to position _endIndex_, exclusive. | |||
| 1. If _p_ matches a Property column of the row in <emu-xref href="#table-datetimeformat-components"></emu-xref>, then | |||
| 1. Let _f_ be the value of _dateTimeFormat_'s internal slot whose name is the Internal Slot column of the matching row. | |||
| 1. Let _v_ be the value of _tm_'s field whose name is the Internal Slot column of the matching row. | |||
| 1. If _p_ is `"quarter"`, then | |||
| 1. Let _v_ be ( _tm_.[[month]] / 3 ) + 1. | |||
There was a problem hiding this comment.
Not really, it assume every 3 months is a quarter and won't prevent month 13 to be 5th quarter in the calendar have more than 12 months.
Also according to
https://www.ecma-international.org/ecma-262/9.0/index.html#sec-month-number
"Months are identified by an integer in the range 0 to 11, inclusive."
The ICU logic is in i18n/smpdtfmt.cpp
case UDAT_QUARTER_FIELD:
if (count >= 4)
_appendSymbol(appendTo, value/3, fSymbols->fQuarters,
fSymbols->fQuartersCount);
else if (count == 3)
_appendSymbol(appendTo, value/3, fSymbols->fShortQuarters,
fSymbols->fShortQuartersCount);
else
zeroPaddingNumber(currentNumberFormat,appendTo, (value/3) + 1, count, maxIntCount);
break;
There was a problem hiding this comment.
A quarter means a fourth of something. So a 5th quarter is not a quarter.
20.3.1.4 Month Number is also wrong for non-Gregorian calendars, then. because 0 to 11 inclusive is not sufficient. Perhaps you should spec this just for gregorian calendars?
Note my node (v8) example referenced above showing numeric formats from 1 to 13 inclusive: https://gist.github.com/srl295/4ce6860667770b5cf563c383897d1b20
There was a problem hiding this comment.
yes, the ICU logic for Java for quarter is broken for the Hebrew calendar, it produces garbage output.
There was a problem hiding this comment.
Is the Ecma262 reference above binding on Ecma402 date formats? I wouldn't think so, otherwise non-12 month calendars would not be supported at all.
|
@FrankYFTang can you comment on the use cases behind the proposal? I know it was added to CLDR 13 years ago, but it would be helpful to get the expected usage. If it is financial reports and company planning (above) I think that argues for at least a settable start date. There's a 2013 CLDR ticket that notes that Japan also has an Apr 1 fiscal start date used with quarters, and also a 2008 ICU ticket that I filed (which I only wrote a test case for now) that shows that formatting is broken for ICU4J |
If the year start with April 1st, instead of Jan 1st, then it is an issue of a different "calendar" rather than an issue with "quarter", right? |
I think it is very common for people to think 2019 Q1 as Jan-March of 2019 and this is what this feature intend to support. Of course, there are other demand for different kind of "calendar system" to be support, but that is beyond what I intend to change here. All what you talk about fiscal year is related to a different calendar system, since it also change the week number and day number start from that year. That is beyond this feature is about. |
Which people, and for what example usage? Have you surveyed different regions? As an international standard, we need to consider more than specific regional usage. I think CLDR did not do this analysis in v1.4 when quarters were added, and should have.
Possibly. But would month numbering be affected (i.e. April be month 0(1st)?) Or week numbering? |
No, a quarter(-year) is a (solar) year divided into 4 time spans of almost equal length, usually rounded to an integer multiple of another time unit: this does not have to be (3) months, but can also be (91+) days or (13+) weeks!
A trimester, by its very name, is 3 months long (which confusingly is about a third of the length of a human pregnancy), whereas a semester (not related to semi as often assumed) is 6 months. Bimester (2 months) and quadmester (4 months) are analogous terms that are used less frequently. Therefore, the proposed definition
Alas, the first …mester does not need to start with January (or whatever the first month is called), because these terms are most frequently used with fiscal and academic years that not necessarily equate to the calendar year. Often, a (summer) break, despite having the same length as teaching terms, is not considered a trimester, which adds to the confusion about the number of trimesters per year and hence their length. In much of Europe, the academic year starts either with September or with October, and the terms may have traditional or local names:
European meteorological seasons are another example of offset trimesters:
Astronomic seasons, lasting from an equinox to a solstice or vice versa (which may also be known by their pagan holidays Ostara, Litha (i.e. Midsummer), Mabon and Yule, have a similar length and contain about 3 zodiac signs (but not their eponymous constellations) each:
These tropical seasons must not be confused with wet and dry seasons or wet, hot and cold seasons in the tropics. While the tropical year is commonly used in Western astrology as well, sometimes astrological seasons are defined as parts of the sidereal year as in South Asia:
Traditional (and sometimes still Julian) English quarter days, which are the origin of academic trimester names, usually are Christian holidays that lay between a solstice or equinox and the end of the month:
or in areas with stronger Celtic heritage, e.g. Scotland:
Solar seasons, best known from Gaelic or Wiccan changeover feasts Imbolc, Beltane, Lammas and Samhain (i.e. Halloween), historically started at the midpoints between equinoxes and solstices – as they do in East Asia:
They have since moved by less than a week to cover 3 complete Gregorian months each:
Apple's reporting quarters are infamously week-based (i.e. usually 13 weeks in each quarter, but every 5 to 6 years there is a 14th week in Q4), see e.g. Slate. The actual start of a country's or company's fiscal year varies, as does the definition of week start.
Old German montane or mining quarters, each named for a Christian holiday contained within itself and thus closely related to Catholic embertides, over time changed from being week-based (starting on a Sunday) to last 3 Gregorian calendar months each.
In conclusion, it probably makes sense to specify at least three terms, e.g.:
|
Thank you for your information. It is very informative. |
|
Since this PR is not actionable until the open questions are addressed, I am converting it to an issue, as discussed in ECMA-402 on September 5. Please direct future discussion to #374. |
ECMA402 decided to abandon tc39/ecma402#345 so we should remove the code here. Bug: v8:9282 Change-Id: I05cbad429ae01bf3debebfed07160b5f53f98a21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825827 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64004}
No description provided.