Saašha, I need to point out that the ISO TC154 folks consider 8601 to be strictly a machine format. Human readability is always a nice feature, to be preferred whenever appropriate. But in the two examples cited below, I doubt that the human readability argument will win.
> -----Original Message-----
> From: Discussion of the Developing Date/Time Standards
> [mailto:[log in to unmask]] On Behalf Of Saašha Metsärantala
> Sent: Tuesday, October 20, 2015 6:29 AM
> To: [log in to unmask]
> Subject: Re: [DATETIME] EDTF to ISO: status and request for feedback
> Thanks to Ray for comments and to Hanna for all use cases. These are the
> kind of use cases I was thinking about was I wrote about "obvious needs".
> > Richard and Saašha have pointed out that years 1 - 99 could be
> misinterpreted as centuries, or viced versa. I want to point out that "year 1"
> is '0001' and "year 99" is '0099'
> Maybe, what I wrote (about two-digits and the x-versus-X-issue) was
> unclear. When I write about risks for confusions or misinterpretations, I
> mean confusions of diverse kinds: I can be confusion by parsers, but also
> confusion by human readers. The latter kind of confusions may happen even
> when the syntax is formally consistent. Sorry for the confusions about
> confusions! ;-)
> > > containing the phrase "next year, in 2016", then the document could be
> written 2015-02-13, 2015-03-13 or 2015-11-13.
> > I am assuming you meant "next year, in 2015". Is this a realistic use case?
> It depends which year the text was / is written. Anyway, I consider that
> Hanna's use cases cover this question well.
> > I want to be sure I understand: 'p' is used instead of 'e' in hex strings
> (because 'e' is a hex character) but only hex strings, and 'e' is fine in a decimal
> string? If that's the case then I don't see any problem with using 'e', since
> there never will be hex in the date string.
> Formally, yes. But a human reader reading "5e4p3" may be easily confused
> and consider "Well, here, they obviously seem to use hexadecimal" and
> misinterpret the string as the hexadecimal "0x05E4" followed by the
> exponent "p3". Of course, such a human reader should read the specs, but
> we could assume that the specs are easier to read and remember (and in the
> longer run easier to use consistently) if the specs readers are not too
> confused. Therefore, I would suggest to avoid a syntax which in other usual
> circumstances mean something totally different. As an "extreme" example, it
> would be confusing for a human reader if we decided to use consistently "2"
> instead of the common "5" (and "5" instead of the common "2"), even if a
> parser could be programmed to address all that consistently.
> > there never will be hex in the date string.
> Probably not, but who knows for sure?