How to get current time as long or ulong?

[Charles Hixson via Digitalmars-d-learn]

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
>
>