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
Hello zeljko,
Tuesday, November 1, 2011, 2:07:50 PM, you wrote:
>> 1. First off, we must correctly take into account DST. That should fix
>> Zejlko's problem.
z> Am I the only one who produces 24/7 services with fpc in the world (and
z> around) ? ;)
For sure no :) I found that problem 2 years ag
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
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 deprec
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 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 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 resta
> 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
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
42 matches
Mail list logo
