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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Apr 15 18:11:50 UTC 2019


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

Jonathan M Davis <issues.dlang at jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang at jmdavisProg.co
                   |                            |m
          Component|phobos                      |dmd

--- Comment #1 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
SysTime's opEquals doesn't care one whit about the time zone. It only cares
about the time in UTC. So, even if drastically different time zones are used,
if they end up being the same time in UTC, then the two SysTimes will be equal.

As for not getting Z in the string with a SysTime created at compile-time that
uses UTC, I don't know how that could be fixed. It has to do with how CTFE and
classes work (which wasn't even possible when SysTime was originally written).
In order to distinguish between UTC and a time zone that happens to line up
with UTC (and some time zones line up during part of the year but not all of
the year), the to*String functions on SysTime compare the _timezone object in
the SysTime with UTC() using the is operator - so it's a pointer comparison.
UTC is a singleton, and only one instance of it should exist. Specifically, it
has these declarations:

    static immutable UTC _utc = new immutable(UTC)();

    static immutable(UTC) opCall() @safe pure nothrow
    {
        return _utc;
    }


However, when CTFE does its thing, it's somehow allocating a separate UTC
instance and then restoring it at runtime without that instance being the same
one that ends up in the static _utc member of the UTC class. It really should
be the same instance, but clearly, it's not. And I don't know enough about how
classes and CTFE work to know whether that's fixable or not.

--


More information about the Digitalmars-d-bugs mailing list