wut: std.datetime.systime.Clock.currStdTime is offset from Jan 1st, 1 AD

[drug]

24.01.2018 03:15, Jonathan M Davis пишет:
> On Tuesday, January 23, 2018 23:27:27 Nathan S. via Digitalmars-d wrote:
>> https://dlang.org/phobos/std_datetime_systime.html#.Clock.currStdTime
>> """
>> @property @trusted long currStdTime(ClockType clockType =
>> ClockType.normal)();
>> Returns the number of hnsecs since midnight, January 1st, 1 A.D.
>> for the current time.
>> """
>>
>> This choice of offset seems Esperanto-like: deliberately chosen
>> to equally inconvenience every user. Is there any advantage to
>> this at all on any platform, or is it just pure badness?
> 
> Your typical user would use Clock.currTime and get a SysTime. The badly
> named "std time" is the internal representation used by SysTime. Being able
> to get at it to convert to other time representations can be useful, but
> most code doesn't need to do anything with it.
> 
> "std time" is from January 1st 1 A.D. because that's the perfect
> representation for implementing ISO 8601, which is the standard that
> std.datetime follows, implementing the proleptic Gregorian calendar (i.e. it
> assumes that the calendar was always the Gregorian calendar and doesn't do
> anything with the Julian calendar).
> 
> https://en.wikipedia.org/wiki/ISO_8601
> https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
> 
> The math is greatly simplified by using January 1st 1 A.D. as the start date
> and by assuming Gregorian for the whole way.
> 
> C# does the same thing with its date/time stuff - it even uses
> hecto-nanoseconds exactly like we do. hnsecs gives you the optimal balance
> between precision and range that can be gotten with 64 bits (it covers from
> about 22,000 B.C. to about 22,000 A.D., whereas IIRC, going one decimal
> place more precise would reduce it to about 200 years in either direction).
> 
> - Jonathan M Davis
> 

I guess he meant it's inconvenient working with c/c++ for example to 
add/subtract difference between epoch in c/c++ and d