On Tuesday, July 05, 2016 16:18:19 Charles Hixson via Digitalmars-d-learn
wrote:
> 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.
MonoTime and stdTime have _nothing_ to do with each other. stdTime is the
number of hecto-nanoseconds since midnight, January 1st, 1 A.D. MonoTime
contains a timestamp in system ticks, and how many of those there are per
second as well as how long ago 0 was are completely system-dependent.
The monotonic time is used for timing things not for anything related to the
wall clock. If what you care about is the wall clock, then use SysTime. If
what you care about is timing stuff, then use MonoTime.
I don't know why you'd want a long for the system time. There's nothing
standard about stdTime (which is why it's a horrible name, but
unfortunately, there really isn't a good name for it like there is with unix
time). SysTime exposes stdTime for the rare code that actually needs it, but
in general, code should either be using SysTime or converting SysTime to
the ISO or ISO extended formats, because those are standard. But you
certainly can store the stdTime somewhere if you want to.
- Jonathan M Davis
