std.datetime & timzone specifier: 2018-11-06T16:52:03+01:00

[Jonathan M Davis]

On Saturday, March 7, 2020 2:43:47 AM MST Robert M. Münch via Digitalmars-d-
learn wrote:
> It looks like std.datetime is not anticipating the +1:00 part of a date
> like: "2018-11-06T16:52:03+01:00"
>
> Those dates are used all over on the internet and I'mm wondering why
> it's not supported. Any reason? Is this +01:00 not ISO conforming?

I take it that you're asking why you don't get the time zone as part of the
string when you call one of the to*String functions? If so, then you're
using LocalTime for your time zone. LocalTime does not print out the UTC
offset as part of the ISO string, whereas other time zones types do (or z in
the case of UTC). This is because the ISO spec says that when the time zone
is not provided, it's assumed to be local time. When I wrote it, I therefore
made it so that the time zone was not put at the end of the string when it
was local time. I don't remember now if I thought that that was required, or
if I just did it, because it corresponded to what happens when you read an
ISO or ISO extended string without a time zone, but at this point, I think
that it was a mistake. Yes, the spec requires that the time zone be treated
as local time when it's not present, but that doesn't mean that the time
zone can't be printed when it's local time. And in general, generating an
ISO string without a time zone is asking for bugs, since the time then won't
match if it's read in on a computer with a different time zone (though it
isn't likely to matter much if it's just printed out).

Unfortunately, I'm not sure that it's reasonable to fix it at this point,
since there's bound to be software that relies on the current behavior.
Given the current behavior, I think that it's usually best to call toUTC
before calling any of the to*String functions unless you're just printing to
a log or something, and there's no real risk of the string being intepreted
as a time value by a program in the future.

- Jonathan M Davis