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

[drug]

24.01.2018 10:25, Jonathan M Davis пишет:
> 
> If you need to interact with time_t, there's SysTime.toUnixTime,
> SysTime.fromUnixTime, stdTimeToUnixTime, and unixTimeToStdTime - assuming of
> course that time_t is unix time. But if it's not, you're kind of screwed in
> general with regards to interacting with anything else, since time_t is
> technically opaque. It's just _usually_ unix time and most stuff is going to
> assume that it is. There's also SysTime.toTM, though tm isn't exactly a fun
> data type to deal with if you're looking to convert anything.
> 
> But if you care about calendar stuff, using January 1st, 1 A.D. as your
> epoch is far cleaner than an arbitrary date like January 1st, 1970. My guess
> is that that epoch was originally selected to try and keep the values small
> in a time where every bit mattered. It's not a particularly good choice
> otherwise, but we've been stuck dealing with it ever since, because that's
> what C and C++ continue to use and what OS APIs typically use.
> 
> - Jonathan M Davis
> 
> 

I'm agree with you that 1 A.D. is better epoch than 1970. IIRC c++11 by 
default uses 1 nsec presicion so even 64 bits are not enough to present 
datetime from January 1st, 1 A.D. to our days.

And by the way I'd like to thank you for your great work - in comparison 
to very (at least for me) inconsistent means c/c++ provide to handle 
date and time, std.datetime is the great pleasure to work with.