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?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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

On 2020-03-07 12:10:27 +0000, Jonathan M Davis said:

> 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?

The problem is, the from* functions give an error, that this is not an ISO date.

I get this in an XML response and extract the datetime:

<ad:creation-date value="2018-11-06T16:52:03+01:00"/>
<ad:modification-date value="2019-03-04T10:14:09+01:00"/>

But I have to do:

DateTime dt = DateTime.fromISOExtString(split("2018-11-06T16:52:03+01:00", regex("\\+"))[0]);

IMO such a string should be feedable directly to the function.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Sunday, 8 March 2020 at 17:28:33 UTC, Robert M. Münch wrote:
[...]
> But I have to do:
>
> DateTime dt = DateTime.fromISOExtString(split("2018-11-06T16:52:03+01:00", regex("\\+"))[0]);

You don't need a regex. split (..., '+') seems to suffice here.

> IMO such a string should be feedable directly to the function.

It took me less than an hour to figure out how to provide a local version of std.datetime named local.datetime:

```local/datetime.d
module local.datetime;
public import std.datetime;
struct DateTime {
   std.datetime.DateTime dt;
   alias dt this;
   static DateTime fromISOExtString (string s)
   {
      import std.array;
      auto arr = split (s, '+');
      import std.exception;
      enforce (arr.length > 0);
      return DateTime (dt.fromISOExtString (arr[0]));
   }
}
```

usage: import local.datetime instead of import std.datetime.

On Sunday, 8 March 2020 at 17:28:33 UTC, Robert M. Münch wrote:
> On 2020-03-07 12:10:27 +0000, Jonathan M Davis said:
>
> DateTime dt = DateTime.fromISOExtString(split("2018-11-06T16:52:03+01:00", regex("\\+"))[0]);
>
> IMO such a string should be feedable directly to the function.

You just need to use SysTime.fromISO*String functions for that, as DateTime does't work with timezones, SysTime do.

On Sunday, March 8, 2020 11:19:33 PM MDT tchaloupka via Digitalmars-d-learn wrote:
> On Sunday, 8 March 2020 at 17:28:33 UTC, Robert M. Münch wrote:
> > On 2020-03-07 12:10:27 +0000, Jonathan M Davis said:
> >
> > DateTime dt =
> > DateTime.fromISOExtString(split("2018-11-06T16:52:03+01:00",
> > regex("\\+"))[0]);
> >
> > IMO such a string should be feedable directly to the function.
>
> You just need to use SysTime.fromISO*String functions for that, as DateTime does't work with timezones, SysTime do.

Exactly. DateTime does not support timezones or fractional seconds. If you want that, then use SysTime. And if you want to get a DateTime from a string such as "2018-11-06T16:52:03+01:00", then just use SysTime's fromISOExtString and convert the result to DateTime. e.g.

auto dt =
    cast(DateTime)SysTime.fromISOExtString("2018-11-06T16:52:03+01:00"");

The documentation for the from*String functions say what they support.

- Jonathan M Davis