[Issue 14172] on windows , core.stdc.time.time function return value is wrong

[via Digitalmars-d-bugs]

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

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

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

--- Comment #1 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
Well, this is a function of the C runtime that it's using, not the D code,
since core.stdc is just a bunch of extern(c) declarations.

I used to have a test in std.datetime to make sure that Clock.currTime was
giving a result within a few seconds of of core.stdc.time.time and had to
remove it, because core.stdc.time.time seemed to be giving incorrect results.
At the time (because I didn't understand enough about the C runtime on
Windows), I concluded that the problem was an MS bug, but I have since verified
that MS gives the correct result with C++, and unless you're building a 64-bit
executable with dmd, you're going to be using dmc's C runtime on Windows. So,
the bug is in dmc, but when I figured that out, I didn't have the time to
figure out how to report a bug on dmdc and haven't gotten around to it since.

I don't know if that's the same bug that you're seeing, but my conclusion was
that the C runtime was applying the local DST to time_t, which is very much the
wrong thing to do and makes it so that the time_t value is off by one hour
during DST. It probably doesn't get noticed simply because if you never give
the time_t value to anything else and only usig with dmc's C runtime, then the
calculations generally work (though I'm willing to bet that they have probelms
around a DST switch).

Now, unless you're south of the equator, DST shouldn't be in effect right now,
so I don't know if what you're seeing is the same problem, but it might be
worth checking whether the value that you're getting from core.stdc.time.time
is off by one hour.

This should print out the difference:

import core.stdc.time;
import std.datetime;
import std.math;
import std.stdio;

void main()
{
    writeln(seconds(abs(Clock.currTime().toUnixTime() - time(null))));
}

And the difference should be 0 or 1 if the C runtime is doing the right thing.

--