The unix time to convert.
import std.datetime.date : DateTime; import std.datetime.timezone : UTC; // Midnight, January 1st, 1970 assert(unixTimeToStdTime(0) == 621_355_968_000_000_000L); assert(SysTime(unixTimeToStdTime(0)) == SysTime(DateTime(1970, 1, 1), UTC())); assert(unixTimeToStdTime(int.max) == 642_830_804_470_000_000L); assert(SysTime(unixTimeToStdTime(int.max)) == SysTime(DateTime(2038, 1, 19, 3, 14, 7), UTC())); assert(unixTimeToStdTime(-127_127) == 621_354_696_730_000_000L); assert(SysTime(unixTimeToStdTime(-127_127)) == SysTime(DateTime(1969, 12, 30, 12, 41, 13), UTC()));
SysTime.fromUnixTime
Converts from unix time (which uses midnight, January 1st, 1970 UTC as its epoch and seconds as its units) to "std time" (which uses midnight, January 1st, 1 A.D. UTC and hnsecs as its units).
The C standard does not specify the representation of time_t, so it is implementation defined. On POSIX systems, unix time is equivalent to time_t, but that's not necessarily true on other systems (e.g. it is not true for the Digital Mars C runtime). So, be careful when using unix time with C functions on non-POSIX systems.
"std time"'s epoch is based on the Proleptic Gregorian Calendar per ISO 8601 and is what SysTime uses internally. However, holding the time as an integer in hnsecs since that epoch technically isn't actually part of the standard, much as it's based on it, so the name "std time" isn't particularly good, but there isn't an official name for it. C# uses "ticks" for the same thing, but they aren't actually clock ticks, and the term "ticks" is used for actual clock ticks for core.time.MonoTime, so it didn't make sense to use the term ticks here. So, for better or worse, std.datetime uses the term "std time" for this.