Automatic Dayligh Saving Setting

[Ronald Heyn]

I would like to know how a c-language program can determine if the site is in standard time or daylight time. I am charged with writing code to notice when the swith from one to the other (if it occurred) was mad so I can trigger some programs to adjust time on other devices.

We supply a product to users all over the US, so some do not swith such as in Arizona.

We currently set up each site with a cron job on the weekend the switch is to occur and would like to see if we can utilize HP UNIX automatic switch capabilities.

[James R. Ferguson]

Hi:

HP-UX will automatically adjust from/to a Daylight Saving Time based on the value of the 'TZ" variable that relates to the rules defined in '/usr/lib/tztab'. This is documented in the manpages for 'tzab(4)' and for 'cron(1M)' [the later in the section, "Spring and Autumn Time Transitions".

As for querying the current setting, a simple shell:

# date "+%Z"

...would do. In my case this shows "EST" or Eastern *Standard* Time.

You could also use a Perl snippet (which leverage the standard libC routines):

# perl -le 'print +((localtime)[8])'

This prints "0" for standard time and "1" when/if you are in Daylight Saving time.

Regards!

...JRF...

[Ronald Heyn]

Thank you for the quick response. Do you know if in this case if a call to tzset would set the value in the variable daylight? If so is that faster execution wise as I will be executing this from a program that essentially runs 24/7?

[James R. Ferguson]

HI:

> Do you know if in this case if a call to tzset would set the value in the variable daylight? If so is that faster execution wise as I will be executing this from a program that essentially runs 24/7?

Your HP-UX server if setup with a TZ rule for Daylight Saving time will perform the shift which in turn will be reflected in the 'tm' structure's 'tm_isdst' field. You can obtain this in C code or in Perl as I noted using 'localtime()'. Depending on how often you call your program, a pure C implementation will probably be faster, though by what measurable amount is left to you to decide.

The overhead of creating a new process to interrogate the state of Daylight savings is certainly the larger component of the whole activity. Hence, if you are going to sample "frequently" and/or for "long" periods, you should encapsulate your sampling in a loop that sleeps; awakens; samples; and returns to sleep, thereby avoiding process instantiation each time.

Regards!

...JRF...

[Ronald Heyn]

Thank you very much for your time. I was pretty sure of the answers prior to asking them. I have been in the programming business for almost 52 years. I just have very little UNIX experience. I am trying to fit this into a system that without disrupting it very much. You gave me some iteas that I will pursue as I generally dislike checking some status over and over again.

Again, thanks for the help.

Ron

[James R. Ferguson]

Hi (again) Ronald:

Welcome to the ITRC forums. If you have found the answers you received helpful, please read :

http://forums11.itrc.hp.com/service/forums/helptips.do?#28

Regards, and good luck.

...JRF...

[Dennis Handly]

>Do you know if in this case if a call to tzset would set the value in the variable daylight?

Of course it won't. tzset(3) says:
The external variable daylight is non-zero only if a summer time zone adjustment is specified in the TZ environment variable.

This means the timeszone has adjustments but not when.

>If so is that faster execution wise

If you sleep every hour, it really doesn't matter how much time you take. You can also do a binary search to find the exact time and sleep the N days until then.

>JRF: Depending on how often you call your program, a pure C implementation will probably be faster, though by what measurable amount is left to you to decide.

Probably not by much.

>The overhead of creating a new process to interrogate the state of Daylight savings is certainly the larger component of the whole activity.

Right.

>I generally dislike checking some status over and over again.

That's where the modified binary search may help. Or Clay's dst.pl.

[doug hosking]

The binary search idea is interesting, but is potentially prone to false results in the case where the government changes the rules for when the time change occurs, someone installs a tztab patch with the new rules but the program in question doesn't notice (because it has already cached the time of the change). This risk could be greatly reduced with negligible overhead by having the program recompute this time occasionally, such as once per day. Assuming the patch isn't installed at the last minute, that should nicely balance correctness and efficiency.

Realistically, the overhead should be so low that a simple while loop that sleeps most of the time should be quite sufficient.

[Ronald Heyn]

Thanks for all the input. I remembered last night that we had tried using the UNIX automatic daylight saving time handling some 12 years ago and we had a problem because we save timestamps in various places in our data. The saved timestamps do not work when we use the timestamp from standard time while in daylight saving and vice versa. We will continue to operate as we do today by keeping all sites in standard time and changing the clock twice a year.

Thanks for all the help

Ron

[Dennis Handly]

>The saved timestamps do not work when we use the timestamp from standard time while in daylight saving and vice versa.

You don't mark them with the timezone? Or that's the problem?
Or always stamp them with UTC?