> So my takeaway is that if we add some docs around our choices here, and our > use of the year extension for the minus, and support leading plusses, we are > in spec without adding ordinal date or basic format support.
Yes, I think for the std lib, being clear on the implementation scope is a good idea. If we think about this pragmatically, the common use cases are parsing machine generated dates like in HTTP headers. Less about parsing human readable UI content. So restricting conformance and documenting clearly seems sound. > On 5 Feb 2021, at 8:23 am, Christopher Keele <[email protected]> wrote: > > It also goes on to say "When the application identifies the need for a > complete representation of a calendar date, it shall be one of the numeric > expressions as follows". So we can in fact ditch the ordinal support! > > So my takeaway is that if we add some docs around our choices here, and our > use of the year extension for the minus, and support leading plusses, we are > in spec without adding ordinal date or basic format support. > > On Thursday, February 4, 2021 at 4:17:58 PM UTC-8 Christopher Keele wrote: > > That is supported by the spec because everything on ISO is per agreement. > > unless it explicitly says that supporting the regular format also requires > > supporting the ordinal one. > > Hmm, would love Kip's take on this, but based on my reading: > > - The minus sign comes with the year extension. Extension support is > optional, with mutual agreement on how much they are extended, and as you > point out, extending it by 0 digits is valid. > So we could just document how we've chosen to support this. But we'd need > to add support for a leading plus as well. > > - Neither basic and extended support, nor calendar vs ordinal date support, > mentions mutual agreement or extensions. > But each section leads off with the ambiguous phrase "When the application > identifies the need for a complete representation of a calendar|ordinal > date"... > So we could just say that Elixir has identified the need for representing > calendar dates, but not ordinal ones? > > On Thursday, February 4, 2021 at 4:03:01 PM UTC-8 José Valim wrote: > Correct, the number of extra digits can be zero. And since we do support > negative years, it is a representation we need to support. > > This conversation makes me think that the simplest is to not support ordinal > dates. We will simply support what is required to represent our own data. So > if we ever support 5 digit years internally, then we change the > formatting/parsing functions too, but not before. > > That is supported by the spec because everything on ISO is per agreement. > unless it explicitly says that supporting the regular format also requires > supporting the ordinal one. > > On Fri, Feb 5, 2021 at 00:53 Christopher Keele <[email protected] <>> wrote: > The most straight-forward source I've been referencing is the wikipedia page > on ISO-8601, augmented by the spec itself and some explanatory articles for > confusing cases. But the wiki does a good job > <https://en.wikipedia.org/wiki/ISO_8601#Years> with this one: > > > It therefore represents years from 0000 to 9999, year 0000 being equal to 1 > > BC and all others AD. > > > To represent years before 0000 or after 9999, the standard also permits... > > [A]n expanded year representation ±YYYYY [that] must have an agreed-upon > > number of extra year digits beyond the four-digit minimum, and it must be > > prefixed with a + or − sign. > > Additionally: > > > The expansion of the year representation[must be used] only by prior > > agreement between the sender and the receiver. > > Also concerning: > > > Values in the range [0000] through [1582] shall only be used by mutual > > agreement of the partners in information interchange. > > On Thursday, February 4, 2021 at 3:46:04 PM UTC-8 José Valim 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] <>> 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] <>. > 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 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/f1636d39-4a9d-4206-b6da-33a10b8e42c6n%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/f1636d39-4a9d-4206-b6da-33a10b8e42c6n%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/c0d90183-befd-411d-9af6-09506584ac95n%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/c0d90183-befd-411d-9af6-09506584ac95n%40googlegroups.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/F33B4F3B-D0AA-4031-9FB4-8B959AA42F41%40gmail.com.
