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

February 23, 2015
Posted by Jonathan M Davis
Permalink
Jonathan M Davis
Permalink
https://issues.dlang.org/show_bug.cgi?id=14172

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

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

--- Comment #1 from Jonathan M Davis <issues.dlang@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.

--
Forums
