is it std.datetime bug?

[drug via Digitalmars-d-learn]

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.