How to get current time as long or ulong?

[Charles Hixson via Digitalmars-d-learn]

On 07/05/2016 05:23 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> 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
The same time needs to be used for two different purposes (or I have to 
keep two separate times).  One time is used during a particular run of 
the program to compare when two different things happened. This needs 
fine discrimination...millisecond level.  The other needs to be used to 
order events happening over a period of time.  This needs to be at the 
hour level, and the minute level is better.  But it needs to work over 
years.  That's why I originally said UnixTime...and UnixTime would work 
fine, but problems might happen if it were in use in 2029(?*).  Since D 
supports a 64 bit time, not using it would seem to be unreasonable.  I 
looked into scaling it, but either I use more than 32 bits, or I need to 
keep two times.  So the long version of SysTime seems to be what I 
want.  That will even let me compare things against books published in 
the Classical Greek period, and doesn't threaten to roll over.  It's 
more precise than I need, but there's no one time of lesser precision 
that will do everything I want.

* This probably wouldn't really cause a problem, as I'm sure that by 
then all the systems the program I'm working on might run on will be 64 
bit systems...but why not avoid the problem from the start.