One more idea: Do we already have something like NowUTC ? Just like
Now, but in UTC.
Maybe that would be something interresting to add. Programs that want
to measure time differences could use it instead of hacking Now.
NowUTC seams to be much more appropriate for time differences then
Now, and
Felipe Monteiro de Carvalho wrote:
One more idea: Do we already have something like NowUTC ? Just like
Now, but in UTC.
Maybe that would be something interresting to add. Programs that want
to measure time differences could use it instead of hacking Now.
NowUTC seams to be much more appropriate
On 2 November 2011 10:31, Mark Morgan Lloyd wrote:
But even in this case, what should happen if the user (or NTP) explicitly
changes the system clock?
NTP client service doesn't explicitly change the system time in one
shot. This could cause all kinds of problems. Instead they slow down
or
In our previous episode, Jonas Maebe said:
That is an symmetrical argument. I could argue exactly the same about
correctness. I don't need it, so please don't force it on all users.
I suppose you meant that what is correct and what not depends on the
specification, rather than than that
On Wed, November 2, 2011 09:56, Marco van de Voort wrote:
.
.
Anyway, there are other reasons to go for a plugin style for this, namely
that you can't predict what libs a certain *nix might need to effectively
monitor the mutation of files. (e.g. that allows to do it in a thread)
But to
In our previous episode, Tomas Hajny said:
I don't get the relation of plugins to the original problem. You don't
need any libc (c*) to solve that problem,
It does if the solution to monitor filesystem change does, or if you need or
want to use a thread for that. So it is not for the time
On 01/11/11 22:01, Marco van de Voort wrote:
But do you agree that _when_ it happens, the directory is rescanned in the same
thread as the gettime() call, outside programmer's control? And that that
breaks code for people that don't expect the runtime to access the harddisk
without they
Am 01.11.2011 22:49, schrieb Henry Vermaak:
On 1 November 2011 21:07, Marco van de Voortmar...@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
On Wed, Nov 2, 2011 at 9:56 AM, Marco van de Voort mar...@stack.nl wrote:
Not entirely related to the discussion, but I don't see that at all. There
is a reason why libc has monotonous time functions.
And I think we should have too:
Now() - Like Michael proposed. Implemented with precision,
Marco van de Voort wrote on Wed, 02 Nov 2011:
The point was just some encouragement to look further than the immediate
need though, and keep the time call relatively cheap. That doesn't exclude
being correct, it just means a more elaborate implementation.
I do not think that reporting the
Felipe Monteiro de Carvalho wrote on Wed, 02 Nov 2011:
Now() - Like Michael proposed. Implemented with precision, but with a
switch for existing code bases to hack it into being fast.
I don't think it is appropriate to add a hack to the RTL for a case
like this. No major incompatibility
On Wednesday 02 of November 2011 11:23:10 michael.vancann...@wisa.be wrote:
On Wed, 2 Nov 2011, Jonas Maebe wrote:
Marco van de Voort wrote on Wed, 02 Nov 2011:
The point was just some encouragement to look further than the immediate
need though, and keep the time call relatively cheap.
On Wed, 2 Nov 2011, zeljko wrote:
On Wednesday 02 of November 2011 11:23:10 michael.vancann...@wisa.be wrote:
On Wed, 2 Nov 2011, Jonas Maebe wrote:
Marco van de Voort wrote on Wed, 02 Nov 2011:
The point was just some encouragement to look further than the immediate
need though, and keep
On Wed, 2 Nov 2011, michael.vancann...@wisa.be wrote:
On Wed, 2 Nov 2011, zeljko wrote:
On Wednesday 02 of November 2011 11:23:10 michael.vancann...@wisa.be wrote:
On Wed, 2 Nov 2011, Jonas Maebe wrote:
Marco van de Voort wrote on Wed, 02 Nov 2011:
The point was just some encouragement
On 02/11/11 13:38, zeljko wrote:
Please see results about Now() and something that I've mentioned about
deprecitation of gettimeofday().According to this test, current
fpgettimeofday() is crap when compared with clock_gettime() (kernel) or
libc calls (I've copied scenario from kylix sysutils).
On Wednesday 02 of November 2011 14:55:36 michael.vancann...@wisa.be wrote:
On Wed, 2 Nov 2011, michael.vancann...@wisa.be wrote:
On Wed, 2 Nov 2011, zeljko wrote:
On Wednesday 02 of November 2011 11:23:10 michael.vancann...@wisa.be
wrote:
On Wed, 2 Nov 2011, Jonas Maebe wrote:
Marco van
On Wed, 2 Nov 2011, zeljko wrote:
On Wednesday 02 of November 2011 14:53:05 you wrote:
You must do also a localtime_r after this call.
clock_gettime returns the same time as gettimeofday.
But point IS in comparing clock_gettime() vs. gettimeofday() which is used by
fpgettimeofday(). I
On Wednesday 02 of November 2011 15:47:46 you wrote:
On Wed, 2 Nov 2011, zeljko wrote:
On Wednesday 02 of November 2011 14:53:05 you wrote:
You must do also a localtime_r after this call.
clock_gettime returns the same time as gettimeofday.
But point IS in comparing clock_gettime() vs.
On Wednesday 02 of November 2011 15:47:46 mich...@freepascal.org wrote:
Ok, let's finish this thread.
1.Now() works as it is - it's even twice faster now since extra fptime call is
avoided (so an + from this thread) :)
2.Programmer (me in this example) need something to re-read timezone, so
On Wed, 2 Nov 2011, zeljko wrote:
On Wednesday 02 of November 2011 15:47:46 mich...@freepascal.org wrote:
Ok, let's finish this thread.
1.Now() works as it is - it's even twice faster now since extra fptime call is
avoided (so an + from this thread) :)
2.Programmer (me in this example)
On Wednesday 02 November 2011 17.13:49 Jonas Maebe wrote:
Yes, the result slower, but it's also correct (as in it makes sure
that the actual local time is returned). Just like all UTF-16 code in
the RTL is slower than what Martin Schreiber would like, and we didn't
change it to UCS-2 when he
Martin Schreiber wrote on Wed, 02 Nov 2011:
On Wednesday 02 November 2011 17.13:49 Jonas Maebe wrote:
Just like all UTF-16 code in
the RTL is slower than what Martin Schreiber would like, and we didn't
change it to UCS-2 when he asked to do so for speed reasons.
???
I never asked this.
On Wednesday 02 November 2011 17.46:07 Jonas Maebe wrote:
Martin Schreiber wrote on Wed, 02 Nov 2011:
On Wednesday 02 November 2011 17.13:49 Jonas Maebe wrote:
Just like all UTF-16 code in
the RTL is slower than what Martin Schreiber would like, and we didn't
change it to UCS-2 when he
michael.vancann...@wisa.be schrieb:
The call will not be merged. Instead, you can just add
ReadTimezoneFile(GetTimezoneFile);
GetLocalTimezone(fptime);
to your code (and add units 'unix' and 'baseunix').
What will happen if these are called on other platforms, which don't
have timezone
Am 02.11.2011 17:33, schrieb Hans-Peter Diettrich:
michael.vancann...@wisa.be schrieb:
The call will not be merged. Instead, you can just add
ReadTimezoneFile(GetTimezoneFile);
GetLocalTimezone(fptime);
to your code (and add units 'unix' and 'baseunix').
What will happen if these are
debated). Also note that on platforms like Windows this would be a
unnecessary call as there the current(!) timezone bias is
located in a
shared memory area which is mapped into each process by the kernel.
Apparently not everything is that transparent under windows:
Al 02/11/11 09:31, En/na Mark Morgan Lloyd ha escrit:
But even in this case, what should happen if the user (or NTP) explicitly
changes the system clock? Ultimately, what matters for relative timing is
ticks-since-boot.
From the link posted before:
On Wed, 02 Nov 2011 07:35:30 +0100, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com wrote:
Maybe that would be something interresting to add. Programs that want
to measure time differences could use it instead of hacking Now.
Well, all what's needed is to differentiate between
On Wednesday 02 November 2011 17.43:56 Martin Schreiber wrote:
On Wednesday 02 November 2011 17.13:49 Jonas Maebe wrote:
Yes, the result slower, but it's also correct (as in it makes sure
that the actual local time is returned). Just like all UTF-16 code in
the RTL is slower than what
Luca Olivetti schrieb:
Al 02/11/11 09:31, En/na Mark Morgan Lloyd ha escrit:
But even in this case, what should happen if the user (or NTP) explicitly
changes the system clock? Ultimately, what matters for relative timing is
ticks-since-boot.
From the link posted before:
Sven Barth schrieb:
The solution mentioned above is a workaround for 2.4 where no fix is in
place. Newer versions of FPC (maybe even 2.6, I don't know about that)
will get an improved/fixed version of Now (how exactly seems to still be
debated).
ACK
Also note that on platforms like Windows
Vinzent Höfler schrieb:
On Wed, 02 Nov 2011 07:35:30 +0100, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com wrote:
Maybe that would be something interresting to add. Programs that want
to measure time differences could use it instead of hacking Now.
Well, all what's needed is
Ludo Brands schrieb:
debated). Also note that on platforms like Windows this would be a
unnecessary call as there the current(!) timezone bias is
located in a
shared memory area which is mapped into each process by the kernel.
Apparently not everything is that transparent under windows:
33 matches
Mail list logo
