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
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 yo
Am 04.11.2011 11:28, schrieb Hans-Peter Diettrich:
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
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
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
__
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
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
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=52912&view=markup
(line 277ff)
That
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 s
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 assu
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
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...
>
On Thu, 03 Nov 2011 17:38:01 +0100, Hans-Peter Diettrich
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=52912&view=markup
(line 277ff)
That
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=52912&view=markup
(line 277ff)
That code doesn't make sense, without additional infor
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().
W
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 wo
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 compatible
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
___
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()
> > > >
>
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 sh
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
> > >
> >
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 i
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 i
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 ansis
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
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
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:
ht
Vinzent Höfler schrieb:
On Wed, 02 Nov 2011 07:35:30 +0100, Felipe Monteiro de Carvalho
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 a politic
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
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:
http://www.kerne
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 wh
On Wed, 02 Nov 2011 07:35:30 +0100, Felipe Monteiro de Carvalho
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 a political-time
and a monotonic/
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:
http://www.kernel.org/doc/man-pages/on
> 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:
http://msdn.micr
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 called
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 fi
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
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.
htt
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 whe
Marco van de Voort wrote on Wed, 02 Nov 2011:
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 yo
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
On Wednesday 02 of November 2011 16:12:49 you wrote:
> On Wed, 2 Nov 2011, zeljko wrote:
> > 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.
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) need
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 Now
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_g
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 don'
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:
>
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 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 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 t
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 ch
Felipe Monteiro de Carvalho wrote:
On Wed, Nov 2, 2011 at 9:56 AM, Marco van de Voort 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. Impleme
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 architect
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. That doesn't exclude
being correct, it just means a more elaborate implementatio
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 wit
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 time
On Wed, Nov 2, 2011 at 9:56 AM, Marco van de Voort 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, but with a
swi
Am 01.11.2011 22:49, schrieb Henry Vermaak:
On 1 November 2011 21:07, Marco van de Voort 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
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 explicite
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 fun
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, 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 tha
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 sp
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
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 it
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
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 does
On 1 November 2011 21:07, Marco van de Voort 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 m
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 localtime.
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 l
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 informatio
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 refr
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 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 ;-)
Luck
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 - fpc-d
Felipe Monteiro de Carvalho schrieb:
On Tue, Nov 1, 2011 at 12:08 PM, Michael Van Canneyt
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
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
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 Now
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 trav
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 pro
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/11/11 12:51, Michael Van Canneyt wrote:
On Tue, 1 Nov 2011, Henry Vermaak wrote:
If you don't do this, daemons that were started before e.g. a daylight
savings update will report the wrong time after the update. Rather
solve this correctly than take short cuts because you want to keep the
> 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
> opera
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.
>>
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, 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 wit
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
sy
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 un
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
> >> giv
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 d
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 w
On Tue, 1 Nov 2011, Felipe Monteiro de Carvalho wrote:
On Tue, Nov 1, 2011 at 12:08 PM, Michael Van Canneyt
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
On Tue, Nov 1, 2011 at 12:08 PM, Michael Van Canneyt
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.
--
Felipe Monteiro de
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 of
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, 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 bas
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. gettimeofday(
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 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 y
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 reaso
1 - 100 of 114 matches
Mail list logo
