ISO 8601 defines the idea of a profile to identify feature compatibility. My observation is that its not worth it - too complex for the std lib. Nevertheless, perfectly ok to implement a subset of features.
If you’d like I can write a PR that is just an ISO8601 conformance statement for Calendar.ISO (given that I have purchased the standard docs and have a reasonable chance of stating it more-or-less correctly. 15 Profiles 15.1 General The ISO 8601 series includes many features and in many cases allows several different formats to represent a single feature or multiple interpretations for a single format. Vendors implementing the ISO 8601 series may implement only a subset of its features, or different representations of a given feature, causing interoperability issues with other implementations. An ISO 8601 profile is a specification of how the ISO 8601 series is to be used for a particular context (application, discipline or community), specifying the necessary features and representations to implement and providing interpretations applicable to the particular context. This document provides one such profile in Annex A. NOTE This document supports the creation of a registration agency for ISO 8601 profiles, which registers > On 5 Feb 2021, at 8:02 am, José Valim <[email protected]> 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] > <mailto:[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] > <mailto:[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/CAGnRm4J1962bJkQFOES%2B9VCbhQTYa6ds0cKBcjj_ZJ7qVnXKzw%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J1962bJkQFOES%2B9VCbhQTYa6ds0cKBcjj_ZJ7qVnXKzw%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/9A3332C3-9F1F-41D9-A740-6798E00FCE40%40gmail.com.
