[fpc-devel] Problem with Now() and time changed by ntpd

[Thaddy]

Gentlemen, gentlemen,

Stop this.

Every proper software clock  ==  UTC, not local time.
The local time should always be on read time, on the fly.

Thaddy

On 2-11-2011 11:48, Marco van de Voort wrote:
> In our previous episode, Jonas Maebe said:
>
>> Anyway: a function that reports the local time is simply
>> the wrong tool for the job if you need a "mostly" monotonic timer that
>> you can query at a high frequency. It may work (and apparently it does
>> for you), but instating a plugin architecture just to be able to keep
>> using it for that purpose is the wrong approach as far as I am
>> concerned.
> True, but as said a very common abuse. Oh, and btw, I forgot, I update a
> clock on my app once a second too (which is not that strange for
> systems that run fullscreen).
>
> Note again that my apps are not in FPC, and could be easily changed. They are
> just meant as illustrations of very common use (and thus of the number of
> support issues you can expect when sb after a lot of debugging finds out
> that the system reacts differently, *JUST* like the issue that initiated
> this thread)
>
>> And even if it is eventually transformed into a pluggable API, fixing
>> it now does not require this plug-in architecture to exist, nor does
>> fixing it make it harder to transform it into a pluggable API
>> afterwards.
> That kind of quick and dirty mentality and pooh,poohing away sideeffects
> (like a noticably slower gettime) without a way to override it is exactly
> what I'm afraid of.
>
>>> But harddisk latency can easily be in the half a second to second magnitude
>>> (and then I don't even count spindowns, and am I accessing directories that
>>> I continously access).
>> If you are stat'ing that file for changes all the time, either the
>> result will be cached or the hard drive won't spin down.
> So this would make FPC apps that use gettime a lot not very eco friendly :-)
>
>> And stat'ing
>> a file will not take half a second when done repeatedly.
> On average or _always_. Big difference. I'm talking about worst case times,
> not average times.
>
>>> In Delphi, for timing of short intervals, typically queryperformance counter
>>> + family is used, but iirc these can't measure longer intervals and are very
>>> imprecise the too (since the CPU frequency might change)
>> For longer intervals you can use gettickcount/gettickcount64 on
>> Windows and fpgettimeofday on Unix. I'm not opposed at all to add some
>> kind of extra "return a monotonic clock value" function somewhere.
> (I'm not sure btw if monotonic is the right term for getticks like
> solutions.  Afaik it is used more for clocks that never go back, e.g.  that
> handle setting clock back by running slower for a while)
>
>>> In our previous episode, Jonas Maebe said:
>>>> If you are in a case where you do want a high precision timer that is only
>>>> adjusted once to the system's timezone (namely when the program was
>>>> started), then I think it is quite reasonable if the RTL does not provide
>>>> such functionality in a standard call.
>>> Not entirely related to the discussion,
>> It is related as far as I am concerned, because the above is how Now()
>> currently works on Unix and as far as I understand, you don't want it
>> to be fixed using a straightforward stat/update check because that may
>> reduce the performance/rate properties of that call.
> I meant that wrt compatibility, since such solution requires an audit of all
> gettime use, and worse awareness. On the other hand I'm not as insensitive
> to the "time should be correct" arguments as people think I am.
>
> Such code change solution would be like having said "monitor timezone info
> yourself and update unixutils.tzsecond if you see changes" to Zeljko.  The
> trouble when porting is that you must first find the problem before you can
> fix it. Argueing that the fix is easy is futile in such case, since
> diagnosing the problem out is nearly always magnitudes more work (and trouble)
>
> Minimizing that is one of the things compatibility is about. More
> importantly, the various requirements don't bite eachother, except that a
> proper solution might require some more functionality in the core set (hence
> plugin route).
>
>>> but I don't see that at all.  There
>>> is a reason why libc has monotonous time functions.
>> Yes, but they are presumably not based on timezone information because
>> that inherently defeats the monotonic property.
> I'm not sure. (see "monotonic" remarks above).
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel