On Thursday 03 of November 2011 21:30:19 Sven Barth wrote:
Am 02.11.2011 19:25, schrieb Ludo Brands:
Apparently not everything is that transparent under windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724944%28v=vs.8
5%2 9.aspx
To inform Explorer that the time zone
Am 04.11.2011 07:55, schrieb zeljko:
But this is on windows ? On linux it does not work without re-reading
tzdata.
Yes, this is Windows only. It was meant as a prove that a timezone
change does influence running processes as well (and not only new ones
as that link stated).
Regards,
Sven
Sven Barth schrieb:
According to Delphi help a TDateTime of 0.0 represents 12/30/1899 12:00
am, while Wikipedia states start counting the seconds from the Unix
epoch of 1970-01-01T00:00:00 UTC.
You are aware that the definition of TDateTime and that of the Unix
timestamp are not supposed to
Sven Barth schrieb:
var
st: TSystemTime;
dt: TDateTime;
begin
GetLocalTime(st);
dt := SystemTimeToDateTime(st);
Writeln(FormatDateTime('c', dt));
GetSystemTime(st);
dt := SystemTimeToDateTime(st);
Writeln(FormatDateTime('c', dt));
Readln;
end.
=== source end ===
As long as
Am 04.11.2011 12:50, schrieb Hans-Peter Diettrich:
But then I wonder why you *ever* want to convert TSystemTime into
TDateTime, when it will be converted back again in the date/time
formatting (and other) procedures. It would be much faster to display or
write out a time stamp, based directly on
On Wednesday 02 of November 2011 23:45:53 Martin Schreiber wrote:
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
On Thursday 03 November 2011 07.44:47 zeljko wrote:
The results with 10'000'000 calls:
FPC Now() MSEgui nowutc() MSEgui nowlocal()
Linux
15.29s 3.39s 3.57s
Windows
10.00s 1.22s 1.37s
Have you tried latest Michael's
03.11.2011 15:04, Martin Schreiber wrote:
No, I can not use trunk because of cpstrnew. I'll try the file Michael sent.
If it is not difficult please explain exact problems with cpstrnew you
have in a separate thread. It is important to know for me what problems
do you have with the new
On Thursday 03 November 2011 08.11:16 Paul Ishenin wrote:
03.11.2011 15:04, Martin Schreiber wrote:
No, I can not use trunk because of cpstrnew. I'll try the file Michael
sent.
If it is not difficult please explain exact problems with cpstrnew you
have in a separate thread. It is
On Thursday 03 of November 2011 08:11:16 Paul Ishenin wrote:
03.11.2011 15:04, Martin Schreiber wrote:
No, I can not use trunk because of cpstrnew. I'll try the file Michael
sent.
If it is not difficult please explain exact problems with cpstrnew you
have in a separate thread. It is
On Thursday 03 November 2011 08.04:17 Martin Schreiber wrote:
On Thursday 03 November 2011 07.44:47 zeljko wrote:
The results with 10'000'000 calls:
FPC Now() MSEgui nowutc() MSEgui nowlocal()
Linux
15.29s 3.39s 3.57s
Windows
10.00s
03.11.2011 15:29, zeljko wrote:
Maybe it's not problem *now*, but looking into mailing list ppl have a
lot of problems, so I think that fear is only problem (at least for me).
People mostly expressed their FUD although there were few problems and
there are some.
But why do you think they
On Thursday 03 of November 2011 08:43:55 Martin Schreiber wrote:
On Thursday 03 November 2011 08.04:17 Martin Schreiber wrote:
On Thursday 03 November 2011 07.44:47 zeljko wrote:
The results with 10'000'000 calls:
FPC Now() MSEgui nowutc() MSEgui nowlocal()
Linux
On Thursday 03 November 2011 09.08:35 zeljko wrote:
That's pretty big difference. Can you compare NowReal() from attached
program with your functions ?
Linux
FPC Now() MSEgui nowutc() MSEgui nowlocal() NowReal()
10.28s 3.45s 3.55s 9.86s
Martin
Am 03.11.2011 02:39, schrieb Hans-Peter Diettrich:
IMO we have to face a problem very similar to Ansi/UTF-8/16: A TDateTime
variable can contain local time in a number of timezones (Ansi), or UTC
values (UTF), which must be interpreted accordingly, e.g. in
DateTimeToStr().
When Delphi
Am 03.11.2011 03:12, schrieb Hans-Peter Diettrich:
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.
I don't think that this really is how Windows
Sven Barth schrieb:
Am 03.11.2011 02:39, schrieb Hans-Peter Diettrich:
IMO we have to face a problem very similar to Ansi/UTF-8/16: A TDateTime
variable can contain local time in a number of timezones (Ansi), or UTC
values (UTF), which must be interpreted accordingly, e.g. in
DateTimeToStr().
Sven Barth schrieb:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912view=markup
(line 277ff)
That code doesn't make sense, without additional
On Thu, 03 Nov 2011 17:38:01 +0100, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912view=markup
On Thursday, November 03, 2011 11:03:36 am Hans-Peter Diettrich wrote:
Sven Barth schrieb:
And functions like DateTimeToStr don't care whether a time value is
local or UTC and in my opinion they even MUST NOT.
Splitting the TDateTime into year, month etc. is done by a DecodeDate...
Pete Cervasio schrieb:
Splitting the TDateTime into year, month etc. is done by a DecodeDate...
function, that *assumes* that TDateTime contains a local time. When you
feed it an UTC time, the result is unusable.
What? How does it assume it's in local time? It assumes it has received
Am 03.11.2011 21:11, schrieb Hans-Peter Diettrich:
Pete Cervasio schrieb:
Splitting the TDateTime into year, month etc. is done by a
DecodeDate...
function, that *assumes* that TDateTime contains a local time. When you
feed it an UTC time, the result is unusable.
What? How does it assume
Am 02.11.2011 19:25, schrieb Ludo Brands:
Apparently not everything is that transparent under windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724944%28v=vs.85%2
9.aspx
To inform Explorer that the time zone has changed, send the
WM_SETTINGCHANGE message.
WM_SETTINGCHANGE
Am 03.11.2011 17:38, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912view=markup
(line 277ff)
That
On Thursday, November 03, 2011 03:11:37 pm Hans-Peter Diettrich wrote:
Pete Cervasio schrieb:
Splitting the TDateTime into year, month etc. is done by a
DecodeDate...
function, that *assumes* that TDateTime contains a local time. When
you
feed it an UTC time, the
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:
On Tuesday 01 of November 2011 06:00:51 waldo kitty wrote:
On 10/31/2011 15:47, Sven Barth wrote:
Maybe a possibilty should be implemented in unit Unix to reread the
timezone file. This wouldn't solve your problem directly, but it would
at least provide the ability to update the time zone
fpgettimeofday uses exactly what it says on the tin: gettimeofday. See
here: http://linux.die.net/man/2/gettimeofday
The fp* functions in Linux by default call directly the kernel instead
of going through libc, thus avoiding the dependency on that library.
Maybe a possibilty should be
On 01.11.2011 06:00, waldo kitty wrote:
On 10/31/2011 15:47, Sven Barth wrote:
Maybe a possibilty should be implemented in unit Unix to reread the
timezone
file. This wouldn't solve your problem directly, but it would at least
provide
the ability to update the time zone information without
On 01.11.2011 10:04, zeljko wrote:
Look into clock_gettime(CLOCK_MONOTONIC) for timing intervals. It
suffers from several less issues due to things like multi-core systems
and external clock settings.
But according to the manpage there is one problem (emphasis mine)
CLOCK_MONOTONIC
On 01.11.2011 09:41, zeljko wrote:
I don't believe that kernel have only gettimeofday() and that kernel
don't know accurate datetime. There's more functions in kernel which can
give you accurate result. gettimeofday() is deprecated, so maybe that's
main reason why it fails to give correct result
On Tuesday 01 of November 2011 11:01:32 Sven Barth wrote:
On 01.11.2011 09:41, zeljko wrote:
I don't believe that kernel have only gettimeofday() and that kernel
don't know accurate datetime. There's more functions in kernel which can
give you accurate result. gettimeofday() is deprecated,
On 01/11/11 10:01, Sven Barth wrote:
On 01.11.2011 09:41, zeljko wrote:
I don't believe that kernel have only gettimeofday() and that kernel
don't know accurate datetime. There's more functions in kernel which can
give you accurate result. gettimeofday() is deprecated, so maybe that's
main
On Tue, 1 Nov 2011, zeljko wrote:
On Tuesday 01 of November 2011 11:01:32 Sven Barth wrote:
On 01.11.2011 09:41, zeljko wrote:
I don't believe that kernel have only gettimeofday() and that kernel
don't know accurate datetime. There's more functions in kernel which can
give you
One idea: In Now if you read the timezones, then store the value of
Now. In subsequent calls check if 1 hour has passed since the last
time the timezones were checked. If yes, then update the timezones and
store this new base value of Now.
This makes a compromise between speed and correctnees. It
On 01.11.2011 11:25, Henry Vermaak wrote:
On 01/11/11 10:01, Sven Barth wrote:
On 01.11.2011 09:41, zeljko wrote:
I don't believe that kernel have only gettimeofday() and that kernel
don't know accurate datetime. There's more functions in kernel which can
give you accurate result.
On Tue, November 1, 2011 11:36, Felipe Monteiro de Carvalho wrote:
One idea: In Now if you read the timezones, then store the value of
Now. In subsequent calls check if 1 hour has passed since the last
time the timezones were checked. If yes, then update the timezones and
store this new base
On 01/11/11 10:30, Michael Van Canneyt wrote:
We'll simply need to store the next moment when the DST correction
changes, compare the result of gettimeofday with that and re-base the
time calculation. If we decide to add some check for the timestamp of
the timezone file - that would make Date(),
On Tue, 1 Nov 2011, Henry Vermaak wrote:
On 01/11/11 10:30, Michael Van Canneyt wrote:
We'll simply need to store the next moment when the DST correction
changes, compare the result of gettimeofday with that and re-base the
time calculation. If we decide to add some check for the timestamp
On Tue, Nov 1, 2011 at 12:08 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
This is something that normally doesn't happen unless you move your system
from one timezone to another or during system setup
In many countries the time zone changes 2 times a year because of the
summer time.
On Tue, 1 Nov 2011, Felipe Monteiro de Carvalho wrote:
On Tue, Nov 1, 2011 at 12:08 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
This is something that normally doesn't happen unless you move your system
from one timezone to another or during system setup
In many countries the
On 01/11/11 11:08, Michael Van Canneyt wrote:
On Tue, 1 Nov 2011, Henry Vermaak wrote:
On 01/11/11 10:30, Michael Van Canneyt wrote:
We'll simply need to store the next moment when the DST correction
changes, compare the result of gettimeofday with that and re-base the
time calculation. If
In our previous episode, Michael Van Canneyt said:
Correct (I had checked as well), but the only purpose that serves
is to check whether the system timezone info has changed.
This is something that normally doesn't happen unless you move your
system from one timezone to another or during
On Tuesday 01 of November 2011 11:25:22 Henry Vermaak wrote:
On 01/11/11 10:01, Sven Barth wrote:
On 01.11.2011 09:41, zeljko wrote:
I don't believe that kernel have only gettimeofday() and that kernel
don't know accurate datetime. There's more functions in kernel which can
give you
On Tue, November 1, 2011 12:49, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Correct (I had checked as well), but the only purpose that serves
is to check whether the system timezone info has changed.
This is something that normally doesn't happen unless you
On Tue, 1 Nov 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Correct (I had checked as well), but the only purpose that serves
is to check whether the system timezone info has changed.
This is something that normally doesn't happen unless you move your
On Tue, 1 Nov 2011, Henry Vermaak wrote:
On 01/11/11 11:08, Michael Van Canneyt wrote:
On Tue, 1 Nov 2011, Henry Vermaak wrote:
On 01/11/11 10:30, Michael Van Canneyt wrote:
We'll simply need to store the next moment when the DST correction
changes, compare the result of gettimeofday
On Tue, 1 Nov 2011, Tomas Hajny wrote:
On Tue, November 1, 2011 12:49, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Correct (I had checked as well), but the only purpose that serves
is to check whether the system timezone info has changed.
This is something
On Tue, November 1, 2011 13:40, Michael Van Canneyt wrote:
On Tue, 1 Nov 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Correct (I had checked as well), but the only purpose that serves
is to check whether the system timezone info has changed.
This is
We'll simply need to store the next moment when the DST correction changes,
compare the result of gettimeofday with that and re-base the time
calculation. If we decide to add some check for the timestamp of the
timezone file - that would make Date(), Time() and Now() VERY expensive
On Tuesday 01 of November 2011 13:51:19 Michael Van Canneyt wrote:
1. First off, we must correctly take into account DST. That should fix
Zejlko's problem.
Am I the only one who produces 24/7 services with fpc in the world (and
around) ? ;)
zeljko
On 01 Nov 2011, at 12:30, Michael Van Canneyt wrote:
The timezone itself does not change, unless you physically move the machine
from, say, Belgium to Russia.
This happens regularly with laptops (and at least I almost never shut down my
laptop when traveling, I just let it hibernate so
On 1-11-2011 15:07, Jonas Maebe wrote:
On 01 Nov 2011, at 12:30, Michael Van Canneyt wrote:
The timezone itself does not change, unless you physically move the machine
from, say, Belgium to Russia.
This happens regularly with laptops (and at least I almost never shut down my
laptop when
Michael Van Canneyt schrieb:
We'll simply need to store the next moment when the DST correction
changes, compare the result of gettimeofday with that and re-base the
time calculation. If we decide to add some check for the timestamp of
the timezone file - that would make Date(), Time() and
Michael Van Canneyt schrieb:
The timezone itself does not change, unless you physically move the
machine from, say, Belgium to Russia.
Then we should include a GPS query, for the actual geographic position,
and adjust the local time accordingly ;-)
DoDi
Felipe Monteiro de Carvalho schrieb:
On Tue, Nov 1, 2011 at 12:08 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
This is something that normally doesn't happen unless you move your system
from one timezone to another or during system setup
In many countries the time zone changes 2
zeljko schrieb:
Am I the only one who produces 24/7 services with fpc in the world (and
around) ? ;)
You seem to be the only one who provides such services based on *local*
time, with 23..25 hours per day ;-)
DoDi
___
fpc-devel maillist -
On Tuesday 01 of November 2011 15:30:43 Hans-Peter Diettrich wrote:
zeljko schrieb:
Am I the only one who produces 24/7 services with fpc in the world (and
around) ? ;)
You seem to be the only one who provides such services based on *local*
time, with 23..25 hours per day ;-)
Lucky me :)
On Tue, 1 Nov 2011, zeljko wrote:
We'll simply need to store the next moment when the DST correction changes,
compare the result of gettimeofday with that and re-base the time
calculation. If we decide to add some check for the timestamp of the
timezone file - that would make Date(),
On Tuesday 01 of November 2011 19:18:38 you wrote:
It will be something like that, yes. I was thinking of introducing a
CheckRefreshTZInfoInterval: integer;
-1 : never check for refresh (current behaviour)
0 : refresh on each call (like LibC, will be new default)
0 : Only refresh
On Tuesday 01 of November 2011 19:32:30 you wrote:
zeljko schrieb:
Now() must return exactly what it's name says. Anything of that is
bug.
Okay, so what's the *exact* definition of Now()?
Is a local calendar system taken into account?
It should return exactly same information as you
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
On 01.11.2011 14:03, Henry Vermaak wrote:
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
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
In our previous episode, Henry Vermaak said:
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?
It has an in memory concept of timezone, and doesn't have to
On 01 Nov 2011, at 23:01, Marco van de Voort wrote:
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
On Mon, 31 Oct 2011, zeljko wrote:
Hi,
I have daemon which uses Now() for getting current date/time, but something is
wrong, time on server changed from 03:00
to 02:00 this weekend, but daemon's Now() was on old time ... until now ...
I've just restarted it and now it applied
new time.
On Monday 31 of October 2011 20:17:46 you wrote:
On Mon, 31 Oct 2011, zeljko wrote:
Hi,
I have daemon which uses Now() for getting current date/time, but
something is wrong, time on server changed from 03:00 to 02:00 this
weekend, but daemon's Now() was on old time ... until now ...
1 - 100 of 106 matches
Mail list logo
