On 02.04.2015 09:19, Jonathan M Davis via Digitalmars-d-learn wrote:
On Tuesday, March 31, 2015 12:47:34 anonymous via Digitalmars-d-learn wrote:
On Tuesday, 31 March 2015 at 11:51:26 UTC, drug wrote:
import std.datetime;
import std.stdio;
void main()
{
long.max.SysTime.toISOExtString.writeln;
}
dmd 2.065 (dpaste.dzfl.pl):
+29228-09-14T02:48:05.4775807
dmd v2.067-devel-c6b489b (using Digger):
-29227-04-20T00:11:54.5224191
could somebody confirm it?
The difference is in time zones. So it's no surprise that the
output is different.
The negative value is probably because the internal `long` wraps
around when the difference from your time zone is added to the
UTC time. I don't know if this is acceptable.
A difference in time zones would result in a different value being printed,
since the default is LocalTime. And of course, it's going to wrap if you
start dealing with long.min or long.max, and the adjustment for your time
zone causes something to be added to long.max or something to be added to
long.min. There really isn't a way around that. About the only thing that I
could think of would be to check for overlow and just force it back to
long.max when it would have gone past it, or force it back to long.min if it
would have gone past that. But that's extra overhead for a use case that's
really never going to happen. Those dates are _well_ outside of the range
that most any program will need. And it's doing the math correctly at the
limits. It's just that that entails wraparound, because we're dealing with
fixed-length integers.
This isn't a bug.
- Jonathan M Davis
Thank you all for your answers. I use long.max as an initializer for my
data sorted by time to place new data to back of the queue. So the only
inconvinience for me is a diagnostic message with negative date. With
your help I've solved it using UTC as the time zone.
