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.
