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

On Tuesday, July 05, 2016 11:43:32 Jonathan M Davis via Digitalmars-d-learn wrote:
> 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.

Actually, I should qualify this. I keep forgetting that time_t is not guaranteed to be unix time on non-POSIX systems. If what you want is time_t, then use C's time function via core.time, but if what you want is actual unix time, then just do Clock.currTime.toUnixTime, since that's the simplest way to do it. If you're using Microsoft's runtime, then time_t is indeed unix time, but it's not for the Digital Mars runtime (and the standard - unfortunately - doesn't require it to be). Digital Mars uses someting that's _close_ to time_t but isn't actually time_t. :(

- Jonathan M Davis

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.

On 7/5/16 3:51 PM, 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.
>>
>>
> 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."

Clock.currTime.toUnixTime? https://dlang.org/library/std/datetime/clock.curr_time.html

SysTime is just a type. What you are looking at is documentation for clock sources, not the type. Clock should give you the wall time.

-Steve

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.


On 07/05/2016 11:53 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Tuesday, July 05, 2016 11:43:32 Jonathan M Davis via Digitalmars-d-learn
> wrote:
>> 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.
> Actually, I should qualify this. I keep forgetting that time_t is not
> guaranteed to be unix time on non-POSIX systems. If what you want is time_t,
> then use C's time function via core.time, but if what you want is actual
> unix time, then just do Clock.currTime.toUnixTime, since that's the simplest
> way to do it. If you're using Microsoft's runtime, then time_t is indeed
> unix time, but it's not for the Digital Mars runtime (and the standard -
> unfortunately - doesn't require it to be). Digital Mars uses someting that's
> _close_ to time_t but isn't actually time_t. :(
>
> - Jonathan M Davis
>
>

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

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

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

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.

On Wed, Jul 06, 2016 at 10:19:19AM -0700, Charles Hixson via Digitalmars-d-learn wrote: [...]
> 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.

The problem with this is that the system clock may change.  Would your program continue to function correctly if, during execution, the user changes the system clock? Or if the OS in the background syncs with a remote NTP server and loses/gains a few seconds/minutes during which events are happening that record timestamps? I.e., some events might have their timestamps out-of-order with the actual sequence of events if you use system time.


T

-- 
I think the conspiracy theorists are out to get us...