is it std.datetime bug?

[Jonathan M Davis via Digitalmars-d-learn]

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