Thank you for confirming the change. It hasn't made any difference
during the tests so far, but it sounds like it soon would have.
I don't really want a long...but an int rolls over too quickly, and
there's no 48 bit time. The time is basically for use over smaller
intervals, but occasionally I may need to compare across multiple
months, or even years. So the reason is because I want one time unit to
have multiple uses. It's going to end up being stored on disk, but
order of access is going to frequently be important, and occasionally
the relative age of quite different entities is going to be important.
For the second use I could use a much lower precision timer, but that
would mean using two separate times for each item.
On 07/05/2016 05:10 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
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
