• drug (11/11) Mar 31 2015 import std.datetime;
• anonymous (6/17) Mar 31 2015 The difference is in time zones. So it's no surprise that the
• Jonathan M Davis via Digitalmars-d-learn (15/36) Apr 01 2015 A difference in time zones would result in a different value being print...
• drug (5/43) Apr 02 2015 Thank you all for your answers. I use long.max as an initializer for my

drug <drug2004 bk.ru> writes:

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?

"anonymous" <anonymous example.com> writes:

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.

Jonathan M Davis via Digitalmars-d-learn writes:

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

drug <drug2004 bk.ru> writes:

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.