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?

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.

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

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.