• Jack Applegame (11/11) Apr 20 2015 I need current system time ISO string with timezone offset. For
• Jonathan M Davis via Digitalmars-d-learn (21/32) Apr 20 2015 The ISO standard requires that a lack of time zone in the string be trea...
• Steven Schveighoffer (8/12) Apr 20 2015 Yeah, I think so. Otherwise you have the case where a time printed in

"Jack Applegame" <japplegame gmail.com> writes:

I need current system time ISO string with timezone offset. For 
example
"2015-04-20T11:00:44.735441+03:00"
but Clock.currTime.toISOExtString doesn't write offset:
"2015-04-20T11:00:44.735441+03:00"

I found workaround, but it looks redundant and needs memory 
allocation:

auto t = Clock.currTime;
t.timezone = new immutable SimpleTimeZone(t.utcOffset);
writeln(t.toISOExtString);

Is there a simple way to get time ISO string with timezone offset?

Jonathan M Davis via Digitalmars-d-learn writes:

On Monday, April 20, 2015 08:10:40 Jack Applegame via Digitalmars-d-learn wrote:
 I need current system time ISO string with timezone offset. For
 example
 "2015-04-20T11:00:44.735441+03:00"
 but Clock.currTime.toISOExtString doesn't write offset:
 "2015-04-20T11:00:44.735441+03:00"

 I found workaround, but it looks redundant and needs memory
 allocation:

 auto t = Clock.currTime;
 t.timezone = new immutable SimpleTimeZone(t.utcOffset);
 writeln(t.toISOExtString);

 Is there a simple way to get time ISO string with timezone offset?

The ISO standard requires that a lack of time zone in the string be treated
as local time, so SysTime, does not print the timezone offset as part of the
string for LocalTime (though the standard requires that the lack of timezone
be treated as local time, not that local time always be printed with no time
zone, so I suppose that the current behavior is not strictly-speaking
necessary). That being the case, you will have to use a different TimeZone
than LocalTime if you want an offset.

Doing toUTC().toISOExtString() will convert it to UTC, and you'll end up
with z for the offset, but obviously, the time will not be the same, since
it'll be adjusted to UTC. However, that's what I'd suggest that folks do in
most cases. And that won't allocate, since UTC is a singelton.

The only other alternative at present (other than adding the offset to the
string yourself) is to do like you're doing and allocate a SimpleTimeZone
(or if you know what your time zone is, use PosixTimeZone or
WindowsTimeZone).

Perhaps, LocalTime should be changed so that it prints the time zone out
(and just make it so that the lack of time zone is read in as local time
rather than treating it that way in both directions), but that's not how it
works currently.

- Jonathan M Davis

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 4/20/15 4:47 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

 Perhaps, LocalTime should be changed so that it prints the time zone out
 (and just make it so that the lack of time zone is read in as local time
 rather than treating it that way in both directions), but that's not how it
 works currently.

Yeah, I think so. Otherwise you have the case where a time printed in 
one local timezone is interpreted differently in a program running in 
another time zone.

I'll also note that one can always do:

t.toISOExtString()[0..$-6];

If you know you don't want the time zone there.

-Steve