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.
