SysTime.fromISOString

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, May 13, 2017 12:56:31 Russel Winder via Digitalmars-d-learn 
wrote:
> On Sat, 2017-05-13 at 04:24 -0700, Jonathan M Davis via Digitalmars-d-
>
> learn wrote:
> > […]
> >
> > YYYY-MM is still truncated and therefore only permitted if
> > applications
> > agree to it.
>
> But didn't that come is as standard in the 2000 standard along with --
> MM-DD for yearless date?
>
> > > For times hh:mm is allowed as well as hh:mm:ss.
> >
> > Rereading the spec, yes, HH:MM is permitted instead of HH:MM:SS, but
> > HH is
> > not, and any truncation of YYYY-MM-DD is considered a truncation and
> > therefore only permitted if the applications involved agree to it.
>
> I'm still going to fight for YYYY-MM, but not to the extent of buying
> the latest standard document from ISO!

As I said, per the standard, YYYY-MM is a truncated representation, and
applications can agree that they'll support it, but it's not required. All
of the sections on truncated representations have language such as "If, by
agreement, truncated representations are used". Each of the from*String
functions are quite specific about what they support. The only portion
that's optional that std.datetime supports is the fractional seconds.

It looks like I need to make HHMM and HH:MM supported to completely follow
the spec (since that's considered a reduction in precision rather than a
truncation and is not listed as optional), but all of the various
truncations are considered optional by the spec and therefore not supported
by std.datetime (and supporting them risks problems with ambiguity - e.g.
you can't distinguish YYYY from HHMM).

> > So, arguably fromISOString and fromISOExtString should be changed to
> > allow
> > HHMM and HH:MM respectively but not HH, YYYY-MM, YYYYMM, or YYYY.
> >
> > > fromIsoString should allow for YYYYMMDDTHHMMSS and YYYY-MM-
> > > DDThh:mm:ss
> > > shouldn't it?
> >
> > YYYYMMDDTHHMMSS is the ISO basic format, and YYYY-MM-DDTHH:MM:SS is
> > the ISO
> > extended format (so, they're both from the same standard, but they're
> > not
> > the same format). fromISOString handles the ISO basic format, and
> > fromISOExtString handles the ISO extended format.
>
> OK, we have my error, two different calls. Of course this means for a
> string from the users you have to attempt a parse in one format and
> then on exception try the other format. From a programmer perspective
> trying to build a SysTime from user input is really awkward. Unless I
> am missing a magic parse function.

> > fromISOString is throwing, because you're giving it the extended
> > format. For
> > that, you need to use fromISOExtString.
>
> From the perspective of someone trying to parse "Input ISO format
> string" really, really awkward. I do not want to use Vladimirs parse
> since it copes with to many formats, I just want IS8601 compliant parse
> (hence not using parse822Format.
>
> You have pointed out why I was getting the error, but I think you can
> accept that the tools that are there for converting strings to IS dates
> need a bit of amendment to make them easy for programmers to work with.

The expectation is that you know which format you're dealing with.
std.datetime is not written with the idea that you're dealing with a string
with an arbitrary date/time format, and it's going to figure out what it is.
It's written with the idea that you know exactly which format the string is
in, and it converts the string based on the rules for that format. The ISO
basic format and ISO extended format are two different formats. And in my
experience, when applications are exchanging information via ISO strings,
it's well-defined which format they're going to use. If you're actually
dealing with a situation where it's not well-defined, then yes, using
std.datetime becomes more painful.

A magic parsing function which supported both the ISO basic format and the
ISO extended format as well as the various truncated versions of those
formats could be written, but it would be very error-prone and in at least
some situations, it would be ambiguous, meaning that it could easily make
the wrong choice. Using the truncated forms really only works when two
applications have agreed on exactly how they're going to handle that, which
is likely the reason that the spec says that they're there for if
applications agree upon them rather than requiring that an application that
supports either the ISO basic format or the ISO extended format supports the
truncated versions.

- Jonathan M Davis