Bug 14172 – on windows , core.stdc.time.time function return value is wrong

Status
NEW
Severity
enhancement
Priority
P4
Component
druntime
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2015-02-12T08:34:12Z
Last change time
2024-12-07T13:34:55Z
Assigned to
No Owner
Creator
Riki
Moved to GitHub: dmd#17293 →

Comments

Comment #0 by lplus — 2015-02-12T08:34:12Z
//on windows core.stdc.time.time function return value is wrong //but use it as localtime param is right //D import core.stdc.time; void main() { time_t t; time(&t); writeln(t); // results a wrong value; very different with vc's result tm* stp = localtime(&t); // but this return value is right; // ... } // C(vc++) #include <time.h> int main() { time_t t; time(&t); printf("%d\n", t); // this is right // ... }
Comment #1 by issues.dlang — 2015-02-23T01:56:45Z
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.
Comment #2 by stanislav.blinov — 2018-11-25T09:22:22Z
Can anyone give an update on this? I can't seem to get different outputs between dmd and vc, but my Windows is on a VirtualBox.
Comment #3 by robert.schadek — 2024-12-07T13:34:55Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17293 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB