On 1 November 2011 21:07, Marco van de Voort <mar...@stack.nl> wrote: > In our previous episode, Henry Vermaak said: >> Also, how cheap is this on Windows? Presumably they will also have to >> deal with potential system services running while updates fix daylight >> saving time changes? If they don't use shared memory for this, I'd >> wager that it's just as slow as libc localtime. > > I doubt Windows has a _file_ based concept of timezone.
Explain? >> I don't think the definition of "acceptable" for the RTL should be "may >> be wrong in corner cases, as long as it's fast". I'm sure you'd agree. > > As Michael explained there are multiple usecases for gettime like > functionality. > > And I agree with him (if only because my business app would break horribly. > Worse, if my business app ran on Linux, rescanning the timezone files in > a thread that called gettime would probably violate realtime constraints and > our quality assurance app would eject valid products because of unexpected > latency due to unforseen harddisk access. Do you even understand how this works on linux? 'localtime' stats the file to see if the timestamp has changed, only then does it reload from the file. It doesn't read the file every time. If you're timing things, you are doing it wrong. If it's more important to you to be fast than correct, then you can weigh up the risks yourself, just don't force it upon all the users of the freepascal compiler. I appear to be wasting my time if two rtl developers can even consider that giving possible erroneous results is an option. Henry _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
