How to get current time as long or ulong?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, July 05, 2016 12:51:54 Charles Hixson via Digitalmars-d-learn 
wrote:
> On 07/05/2016 11:43 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Tuesday, July 05, 2016 11:16:31 Charles Hixson via Digitalmars-d-learn
> >
> > wrote:
> >> What I'm looking for is the opposite of the "FromUnixTime" function.
> >
> > SysTime has toUnixTime, which is right above fromUnixTime in the
> > documentation.
> >
> > 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.
> >
> > - Jonathan M Davis
>
> That's what I want, but I'm worried by the documentation saying:
> " This has no relation to the wall clock time, as the wall clock time
> can be adjusted (e.g. by NTP), whereas the monotonic clock always moves
> forward."
> What I want is the system clock time, which *is* adjusted by NTP.  I
> know it's not guaranteed monotonic, but different computers should have
> the same time (or be able to be synchronized to the same NTP time).  And
> it's "approximately monotonic".  time_t is fine, as 32 bit hardware is
> becoming scarce, and the application I'm working on will probably never
> encounter any.  (More than 32 bits of precision is required as I don't
> want it to roll over every 42.5 days.)
>
> I understand why some purposes would really want a monotonic time, but
> that's not a strong constraint for me.  But I do want it to be a long or
> ulong.  (I don't really care where 0 is.  What I'm using now is:
> alias    long    ClockT;
> ClockT    now()    {    return    MonoTime.currTime();    }
> And it's working fine during testing, but the documentation about the
> setting of MonoTime bothers me.

The Monotonic clock has nothing to do with the wall clock. It's giving the
number of system clock ticks which have occurred since some arbitrary time
that the system clock decided was 0, and the number of ticks per second is
completely system dependent. You wouldn't even want to share that number
between programs, let alone between runs of the same programe or between
computers. It's used for timing, not for knowing what time it is. e.g.

auto before = MonoTime.currTime;
// ... do a bunch of stuff
auto after = Monotime.currTime;

// The amount of time that that stuff took
auto diff = after - before;

It's the difference that becomes meaningful. The actual values of before and
after would be meaningless outside of this exact run of the program. What
makes the monotonic clock work for timing unlike the wall clock is that it
always moves forward by a fixed number of ticks per second. It's all about
timing and not at all about determing what time of day it is.

The wall clock time, on the other hand, is all about the time of day. It's
this particular hour, minute, second, etc. on this particular day of this
particular month of this particular year. And because the system's wall
clock time can be changed (be it because of NTP or someone manually changing
the time - or even because of a change in time zone if you're dealing with
the local time), it is not guaranteed to always move forward at a fixed
rate. It could change radically, which is why it does not work for timing.
It's all about knowing what time of day that something happened.

There really should never be a question of whether the monotonic time or the
wall clock time is appropriate. If you're ever asking that question, then
you almost certainly don't understand what they are.

If what you want is to time stuff (e.g. this happened x minutes into the run
of this program or this operation took y seconds), then you want the
monotonic time. If what you want is to know when something happens - i.e.
the time of day and/or date - then what you want is the wall clock time.
What you're using it for should make it obvious which you need.

But I would have to know more about what you're trying to do to have any
clue what you should be using. And I don't know why you would be so
interested in having the time as an integral value. That's usually a bad
idea. It's almost always better to use a time type that actually involves
units and context rather than a naked integral value.

- Jonathan M Davis