Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2013-10

Possible error with Now function over summer/winter time change?

7 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

David Taylor

I noticed that over the clock change in the Autumn my wall clock continued to display summer time rather than winter time - my guess is that the Now function doesn't check for a change in the minutes offset very frequently, if at all since it was first called. Restarting the program fixed the problem, but it would be nice to have the fix in the code.

This with FPC for the Raspberry Pi.

Source:
http://www.satsignal.eu/raspberry-pi/DigitalClock.html

Code extract:

procedure TClockForm.TimerClockTimer (Sender: TObject);
var
   when: TDateTime;
   hours, minutes, seconds, th: Word;
begin
   when := Now;
   DecodeTime (when, hours, minutes, seconds, th);
   if seconds  FOldSeconds then
     begin
     FOldSeconds := seconds;
     LabelHHMM.Caption := FormatDateTime ('hh:mm', when);
     LabelHHMM.Update;
     LabelSS.Caption := FormatDateTime (' ss', when);
     LabelSS.Update;
     if hours  FOldHours then
       begin
       FOldHours := hours;
       LabelDate.Caption := FormatDateTime ('yyyy-mmm-dd', when);
       LabelDay.Caption := FormatDateTime ('dddd', when);
       LabelDate.Left := (ClientWidth - LabelDate.Width) div 2;
       LabelDay.Left := (ClientWidth - LabelDay.Width) div 2;
       end;
     end;
end;

Thanks.

David Web: http://www.satsignal.eu
Michael Van Canneyt
to David Taylor
David Taylor wrote 5 lines
I noticed that over the clock change in the Autumn my wall clock continued to display summer time rather than winter time - my guess is that the Now function doesn't check for a change in the minutes offset very frequently, if at all since it was first called. Restarting the program fixed the problem, but it would be nice to have the fix in the code.

It is a known problem.

Doing this 100% correctly involves re-reading the timezone file at every call of Now() or Date(). Clearly, this is a huge performance impact, severely skewing the time information.

So this is not done.

The "unix" unit contains

Procedure ReReadLocalTime;

which will re-initialize the necessary variables. You can call this routine at regular intervals as you see fit.

In your case, you may want to insert a call to this after every clock update, which would be once a second.

Michael.

Show quoted text 46 lines
This with FPC for the Raspberry Pi. Source: http://www.satsignal.eu/raspberry-pi/DigitalClock.html Code extract: procedure TClockForm.TimerClockTimer (Sender: TObject); var when: TDateTime; hours, minutes, seconds, th: Word; begin when := Now; DecodeTime (when, hours, minutes, seconds, th); if seconds FOldSeconds then begin FOldSeconds := seconds; LabelHHMM.Caption := FormatDateTime ('hh:mm', when); LabelHHMM.Update; LabelSS.Caption := FormatDateTime (' ss', when); LabelSS.Update; if hours FOldHours then begin FOldHours := hours; LabelDate.Caption := FormatDateTime ('yyyy-mmm-dd', when); LabelDay.Caption := FormatDateTime ('dddd', when); LabelDate.Left := (ClientWidth - LabelDate.Width) div 2; LabelDay.Left := (ClientWidth - LabelDay.Width) div 2; end; end; end; Thanks. -- David Web: http://www.satsignal.eu -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
David Taylor
to Michael Van Canneyt

On 27/10/2013 16:40, Michael Van Canneyt wrote:
[]

Show quoted text 20 lines
It is a known problem. Doing this 100% correctly involves re-reading the timezone file at every call of Now() or Date(). Clearly, this is a huge performance impact, severely skewing the time information. So this is not done. The "unix" unit contains Procedure ReReadLocalTime; which will re-initialize the necessary variables. You can call this routine at regular intervals as you see fit. In your case, you may want to insert a call to this after every clock update, which would be once a second. Michael.

Thanks, Michael, that's most helpful, I can call it once an hour which will be more than enough.

However, it seems that in the version I have for the Raspberry Pi (Laz: 1.0.6 FPC: 2.6.0) the "Unix" unit does not contain this procedure. I did find the source code for it, but I don't want to have to ask folk who might want to compile the clock program to have to also copy many lines of code from the Unix unit. (Oh, and I tried both "unix" and "Unix" - both seemed to work.)

Am I missing something?

Thanks

David Web: http://www.satsignal.eu
Sven Barth
to David Taylor
David Taylor wrote 34 lines
On 27/10/2013 16:40, Michael Van Canneyt wrote: [] > It is a known problem. > > Doing this 100% correctly involves re-reading the timezone file at every > call of Now() or Date(). > Clearly, this is a huge performance impact, severely skewing the time > information. > > So this is not done. > > The "unix" unit contains > > Procedure ReReadLocalTime; > > which will re-initialize the necessary variables. You can call this > routine at regular intervals as you see fit. > > In your case, you may want to insert a call to this after every clock > update, which would be once a second. > > Michael. Thanks, Michael, that's most helpful, I can call it once an hour which will be more than enough. However, it seems that in the version I have for the Raspberry Pi (Laz: 1.0.6 FPC: 2.6.0) the "Unix" unit does not contain this procedure. I did find the source code for it, but I don't want to have to ask folk who might want to compile the clock program to have to also copy many lines of code from the Unix unit. (Oh, and I tried both "unix" and "Unix" - both seemed to work.) Am I missing something?

It's only in trunk for now.

@Marco: It's likely a good candidate to merge to 2.6.3 (it's revision 19569).

Regards,
Sven

Sven Barth
to Sven Barth
Sven Barth wrote 37 lines
Am 28.10.2013 08:49, schrieb David Taylor: > On 27/10/2013 16:40, Michael Van Canneyt wrote: > [] >> It is a known problem. >> >> Doing this 100% correctly involves re-reading the timezone file at >> every >> call of Now() or Date(). >> Clearly, this is a huge performance impact, severely skewing the time >> information. >> >> So this is not done. >> >> The "unix" unit contains >> >> Procedure ReReadLocalTime; >> >> which will re-initialize the necessary variables. You can call this >> routine at regular intervals as you see fit. >> >> In your case, you may want to insert a call to this after every clock >> update, which would be once a second. >> >> Michael. > > Thanks, Michael, that's most helpful, I can call it once an hour > which will be more than enough. > > However, it seems that in the version I have for the Raspberry Pi > (Laz: 1.0.6 FPC: 2.6.0) the "Unix" unit does not contain this > procedure. I did find the source code for it, but I don't want to > have to ask folk who might want to compile the clock program to have > to also copy many lines of code from the Unix unit. (Oh, and I tried > both "unix" and "Unix" - both seemed to work.) > > Am I missing something? It's only in trunk for now.

It has been merged to 2.6.3 and thus will be part of 2.6.4.

Regards,
Sven

David Taylor
to Sven Barth

On 07/11/2013 15:10, Sven Barth wrote:
[]

It has been merged to 2.6.3 and thus will be part of 2.6.4. Regards, Sven

Thanks. Would 2.6.4 be announced here? Will it be available for the Raspberry Pi, and if so, when? (Just asking, no rush.)

David Web: http://www.satsignal.eu
Sven Barth
to David Taylor
David Taylor wrote 8 lines
On 07/11/2013 15:10, Sven Barth wrote: [] > It has been merged to 2.6.3 and thus will be part of 2.6.4. > > Regards, > Sven Thanks.

You're welcome

Would 2.6.4 be announced here?

Yes.

Will it be available for the Raspberry Pi,

Don't know. Depends on whether someone packages a release for the Pi.

and if so, when? (Just asking, no rush.)

When it's done? ;) (Sorry, I don't know)

Regards,
Sven