On 07/06/2016 10:32 AM, H. S. Teoh via Digitalmars-d-learn wrote:
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
It would err in a trivial way, which might require reloading something
from disk. So an occasional mistake of that nature isn't a problem.
