Per the standard: The Gregorian calendar defines a calendar year to be either 365 or 366 days, which begins on January 1 and ends on December 31. Each Gregorian calendar year can be identified by a 4-digit ordinal number beginning with ‘0000’ for year zero, through ‘9999’.
4.3.2 Calendar year and years duration The calendar year and years duration are represented as follows: a) Implied: [YYYY] EXAMPLE 1 ‘1985’ (calendar year 1985) b) Explicit: [i][“Y”] EXAMPLE 2 ‘12Y’ (twelve years) The number of digits may exceed 4 in the case of expanded representation, in which case the year number may be preceded by a minus sign to indicate a year preceding year zero. Only the Expanded (by agreement) year allows more than 4 digits and allows a sign (+ or -) > On 5 Feb 2021, at 7:45 am, José Valim <[email protected]> wrote: > > > In fact now that I think about it we are probably violating the spec today: > > we support negative signs to indicate BC for 4-digit years. By my reading > > of the spec we should be requiring that negative years supply 5 digits. > > My understanding is that the number of extra digit years is adjustable. So it > could be 0 extra digits or even 2. To quote Wikipedia: > > > The "basic" format for year 0 is the four-digit form 0000, which equals the > > historical year 1 BC. Several "expanded" formats are possible: −0000 and > > +0000, as well as five- and six-digit versions. > > Source: https://en.m.wikipedia.org/wiki/Year_zero > <https://en.m.wikipedia.org/wiki/Year_zero> > > I am not sure if this means the basic format does not support extra digits > nor negative years. If they do, then there may be ambiguity. > > On Fri, Feb 5, 2021 at 00:22 Christopher Keele <[email protected] > <mailto:[email protected]>> wrote: > > Here is another question: if we are going to parse ordinals by default, how > > am I going to format to the ordinal format? Use strftime exclusively? > > I'm fine with that, to me this is a case of following the parsing spec and > being liberal in what we accept, conservative in what we emit (by default). > > On Thursday, February 4, 2021 at 3:20:21 PM UTC-8 Christopher Keele wrote: > > Ordinal also has both extended and basic forms too. > > Yup, basic/extended can apply to the entire date/time/datetime string (but > must be universally applied to it, saving at least some headache). > > > The distinction between basic ordinal and basic DateTime is a single > > character > > I agree that basic ordinals is possibly the worst way to format a date, for > the reasons you describe. But it is technically unambiguous, and > > > There will also be ambiguity if we ever decide to support more than four > > digits on the year. > > This is technically not true for 5-digit years, so long as we choose to use > ISO-8601: it has a provision for this by prefixing the year with a plus or > minus. This is described as being 'by agreement only' though so omitted from > my envisioned scope. > > In fact now that I think about it we are probably violating the spec today: > we support negative signs to indicate BC for 4-digit years. By my reading of > the spec we should be requiring that negative years supply 5 digits. > > > At this point I wonder why add [ordinal dates] to the stdlib. > > My motive here really is just to be spec-compliant. There may be a point > where we decide we are going off-spec to avoid many of the complexities > raised in this discussion, happy to have that conversation too (though > probably should be its own thread?) > On Thursday, February 4, 2021 at 3:08:00 PM UTC-8 José Valim wrote: > Ah, thanks Kip. Ordinal also has both extended and basic forms too. > > Here is another question: if we are going to parse ordinals by default, how > am I going to format to the ordinal format? Use strftime exclusively? > > The other annoyance is while an extended ordinal is distinct enough from a > regular extended DateTime, the distinction between basic ordinal and basic > DateTime is a single character: “2020012134523”. There will also be ambiguity > if we ever decide to support more than four digits on the year. This is > enough to say that: > > * it is not possible to parse all formats within a single function without > additional user instructions > > * if the basic format supports both regular and ordinal, there can be > ambiguity if 5 year digits are ever supported in the future > > This is enough information to me that ordinal should be its own thing, with > possibly basic_ordinal and extended_ordinal, but at this point I wonder why > add it to the stdlib. > > On Thu, Feb 4, 2021 at 23:50 Kip Cole <[email protected] <>> wrote: > From ISO 8601-1:2019(E): > > 5.2.3 Ordinal date > > > 5.2.3.1 Complete representations > > A complete representation of an ordinal date shall be as follows. > > a) Basic format: [year][dayo] EXAMPLE 1 1985102 > > b) Extended format: [year][“-”][dayo] EXAMPLE 2 1985-102 > > If by agreement, expanded representations are used, the formats shall be as > specified below. The interchange parties shall agree on the additional number > of digits in the time scale component year. > > 5.2.3.2 Expanded representations > > In the examples below it has been agreed to expand the time scale component > year with two digits. > > a) Basic format: [±][year(6)][dayo] EXAMPLE 1 +001985102 > > b) Extended format: [±][year(6)][“-”][dayo] EXAMPLE 2 +001985-102 > > >> On 5 Feb 2021, at 6:45 am, José Valim <[email protected] <>> wrote: >> >> >> I like José's suggesting of supporting a flag, but it gets kind of >> complicated as there are several dimensions here even in our reduced case. >> Dates, times, and datetimes support either basic or extended notations; >> dates and datetimes support calendar dates or ordinal dates; both are >> applicable to any parsing. >> >> Are we 100% sure that ordinal datetimes are part of ISO8601? Kip, can you >> please confirm? >> >> If we went with this approach I'd lean towards always accepting either form >> for one of the dimensions, and using flags to the sigil and parsing >> functions to indicate intent for the other. >> >> I am not necessarily worried about sigils because sigils are always >> compile-time literals. It is probably fine to enforce a given format there >> rather than multiple ones. >> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "elixir-lang-core" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/elixir-lang-core/CcXpeMQhsmU/unsubscribe >> <https://groups.google.com/d/topic/elixir-lang-core/CcXpeMQhsmU/unsubscribe>. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JNeGkCNW_6ic2XkxTkFV3uyMT%2B3EZYJuguhzzZfpOnpQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JNeGkCNW_6ic2XkxTkFV3uyMT%2B3EZYJuguhzzZfpOnpQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/15198E56-9D02-4A0E-8E6D-AB905531112A%40gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/15198E56-9D02-4A0E-8E6D-AB905531112A%40gmail.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/d23cddf9-5f10-4618-b6c7-a0902b828bd2n%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/d23cddf9-5f10-4618-b6c7-a0902b828bd2n%40googlegroups.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/CcXpeMQhsmU/unsubscribe > <https://groups.google.com/d/topic/elixir-lang-core/CcXpeMQhsmU/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Lxe9tgq%3DHhBaPiyYmdj%3DJHG2WKN3RqPzWi2t0FvuSEvw%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Lxe9tgq%3DHhBaPiyYmdj%3DJHG2WKN3RqPzWi2t0FvuSEvw%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/9EE123AF-BF27-462C-AF79-3B9406C1DD5D%40gmail.com.
