[Issue 19808] SysTime gives different results at compile vs. run time execution

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=19808

--- Comment #4 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
(In reply to anonymous4 from comment #2)
> I believe ISO 8601 even provides rationale that time zones are too messy to
> address so it doesn't and only specifies UTC offset, which is not a time
> zone, and offset 0 is UTC.

The bit with Z for when the time zone is UTC comes from ISO 8601. Otherwise, it
handles all time zones as offsets from UTC and does not get into
America/Los_Angeles or Pacific Standard Time or any other form of defining a
time zone, which means that an ISO 8601 timestamp really just gives you the
offset from UTC at the point in time that the timestamp is for, not the time
zone that it's really associated with, with UTC itself being the only
exception.

(In reply to David Eckardt from comment #3)
> Jonathan, I see the problem. I wonder how `is` at run-time for class objects
> created at compile-time is supposed to work, as it compares memory
> addresses, but IIUC CTFE doesn’t use a model of addressed memory.
> 
> Bummer.

I don't know. CTFE is one of those things which has grown organically over
time, which makes some aspects of it kind of messy. However, in this case, your
example isn't actually using is at compile-time, because the strings are being
generated at runtime. The issue is that the UTC object that's created at
compile-time is then not the one that ends up in the static variable to be used
at runtime when calling UTC(). I don't know what would happen if you called
toISOExtString at compile-time. I'd have to test it. It might not even work due
to using a pointer comparison.

--