I guess I was expressing myself poorly, probably due to muddled thinking
about the representation of time.
Based on various hints from you and others my current guess is that I
should use:
long now() { return Clock.currTime().stdTime; }
IIUC this should return the current system clock time offset to start at
the start of 1 C.E. (with a standard systematic error that common across
all machines allowing for drift since the last time their clocks were
updated by NTP). And that this is the supported way to get this time.
(Which is probably about the same as MonoTime.currTime(), but *is*
updated when NTP updates the system clock.) And which is standardly a
64 bit number.
On 07/05/2016 11:53 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Tuesday, July 05, 2016 11:43:32 Jonathan M Davis via Digitalmars-d-learn
wrote:
But if what you want is a time_t, and you don't want to deal with SysTime,
there's no point in using std.datetime. Just use core.time to call C's time
function.
Actually, I should qualify this. I keep forgetting that time_t is not
guaranteed to be unix time on non-POSIX systems. If what you want is time_t,
then use C's time function via core.time, but if what you want is actual
unix time, then just do Clock.currTime.toUnixTime, since that's the simplest
way to do it. If you're using Microsoft's runtime, then time_t is indeed
unix time, but it's not for the Digital Mars runtime (and the standard -
unfortunately - doesn't require it to be). Digital Mars uses someting that's
_close_ to time_t but isn't actually time_t. :(
- Jonathan M Davis
