Testing for daylight savings on a GMT server

[snoopy_]

Hello,
I have a server that is set to GMT and it needs to interact with
other servers that are not and the other servers also observe daylight
savings time adjustments. I am trying to re-write some scripts that do
not require any changes due to the timechange, I thought I found the
cure via perl's localtime function, but this last weekend showed me
that since my box is set to GMT it doesn't care about DST and perl
won't pick up the change.

Here's what I was using (our code standard is ksh):

chk_dst()
{
DST=`/usr/bin/perl -e '($isdst) = (localtime)[8]; print
"$isdst\n";'`
if [ $DST == 0 ]; then
TIME1=14
TIME2=19
elif [ $DST == 1 ]; then
TIME1=15
TIME2=20
elif [ $DST -ge -1 ]; then
echo "Cannot determine system time" >> /tmp/dstTime.out
fi
}

I was hopping to see a "0" when we are out of DST, and a "1" when we
were in DST. Neither seems to be the case. I also tried setting my
TZ variable to a local time, but I haven't seen any changes. It
appears the issue is that since my box is set to GMT, I won't be able
to use perl to get the DST info. Any suggestions?

P.S. System OS is Solaris 2.8.

 

[Paul Lalli]

I have a server that is set to GMT and it needs to interact with
other servers that are not and the other servers also observe daylight
savings time adjustments. I am trying to re-write some scripts that do
not require any changes due to the timechange, I thought I found the
cure via perl's localtime function, but this last weekend showed me
that since my box is set to GMT it doesn't care about DST and perl
won't pick up the change.

Here's what I was using (our code standard is ksh):

chk_dst()
{
DST=`/usr/bin/perl -e '($isdst) = (localtime)[8]; print
"$isdst\n";'`
if [ $DST == 0 ]; then
TIME1=14
TIME2=19
elif [ $DST == 1 ]; then
TIME1=15
TIME2=20
elif [ $DST -ge -1 ]; then
echo "Cannot determine system time" >> /tmp/dstTime.out
fi
}

I was hopping to see a "0" when we are out of DST, and a "1" when we
were in DST. Neither seems to be the case. I also tried setting my
TZ variable to a local time, but I haven't seen any changes. It
appears the issue is that since my box is set to GMT, I won't be able
to use perl to get the DST info. Any suggestions?

Are you sure $TZ didn't affect anything? It seems to for me...
$ echo $TZ
US/Eastern
$ perl -le'print ((localtime(time))[8])'
0
$ perl -le'print ((localtime(time - 60*60*24*3))[8])'
1
$ export TZ=GMT
$ perl -le'print ((localtime(time))[8])'
0
$ perl -le'print ((localtime(time - 60*60*24*3))[8])'
0

I'm first checking the isDST value of the current day/time (2005-10-31
11:48:00), then of 3 days previous. Then I change timezones to GMT,
and check the two dates again. When in Eastern time, isDST is false
for right now, but true for three days ago, while it's always false
when in GMT.

Paul Lalli

 

[joe]

I have a server that is set to GMT and it needs to interact with
other servers that are not and the other servers also observe
daylight savings time adjustments. I am trying to re-write some
scripts that do not require any changes due to the timechange, I
thought I found the cure via perl's localtime function, but this
last weekend showed me that since my box is set to GMT it doesn't
care about DST and perl won't pick up the change.

Here's what I was using (our code standard is ksh):

chk_dst()
{
DST=`/usr/bin/perl -e '($isdst) = (localtime)[8]; print
"$isdst\n";'`
if [ $DST == 0 ]; then
TIME1=14
TIME2=19
elif [ $DST == 1 ]; then
TIME1=15
TIME2=20
elif [ $DST -ge -1 ]; then
echo "Cannot determine system time" >> /tmp/dstTime.out
fi
}

I was hopping to see a "0" when we are out of DST, and a "1" when
we were in DST. Neither seems to be the case. I also tried setting
my TZ variable to a local time, but I haven't seen any changes. It
appears the issue is that since my box is set to GMT, I won't be
able to use perl to get the DST info. Any suggestions?

P.S. System OS is Solaris 2.8.

I'm not entirely sure I understand what you're asking, but if all you
want to do is find out if DST is in effect currently for some other
timezone, just prefix a TZ assignment to the perl script, eg

TZ=CST6DST /usr/bin/perl -e '($isdst) = (localtime)[8]; print "$isdst\n";'

Joe

 

[Mothra]

Hello snoopy,

Hello,
I have a server that is set to GMT and it needs to interact with
other servers that are not and the other servers also observe
daylight savings time adjustments. I am trying to re-write some
scripts that do not require any changes due to the timechange, I
thought I found the cure via perl's localtime function, but this last
weekend showed me that since my box is set to GMT it doesn't care
about DST and perl won't pick up the change.
(snipped)

P.S. System OS is Solaris 2.8.

From the DateTime Docs

* is_dst
Returns a boolean indicating whether or not the datetime object is
currently in Daylight Saving Time or not.

So something like this should give you what you need.

use strict;
use warnings;
use DateTime;

print DateTime->today( time_zone => 'America/Los_Angeles')->is_dst;

Hope this helps

Mothra

 

[Enrique Perez-Terron]

I have a server that is set to GMT and it needs to interact with
other servers that are not and the other servers also observe daylight
savings time adjustments. I am trying to re-write some scripts that do
not require any changes due to the timechange, I thought I found the
cure via perl's localtime function, but this last weekend showed me
that since my box is set to GMT it doesn't care about DST and perl
won't pick up the change.

Here's what I was using (our code standard is ksh):

chk_dst()
{
DST=`/usr/bin/perl -e '($isdst) = (localtime)[8]; print
"$isdst\n";'`
if [ $DST == 0 ]; then
TIME1=14
TIME2=19
elif [ $DST == 1 ]; then
TIME1=15
TIME2=20
elif [ $DST -ge -1 ]; then
echo "Cannot determine system time" >> /tmp/dstTime.out
fi
}

I was hopping to see a "0" when we are out of DST, and a "1" when we
were in DST. Neither seems to be the case. I also tried setting my
TZ variable to a local time, but I haven't seen any changes. It
appears the issue is that since my box is set to GMT, I won't be able
to use perl to get the DST info. Any suggestions?

Are you sure $TZ didn't affect anything? It seems to for me...
$ echo $TZ
US/Eastern
$ perl -le'print ((localtime(time))[8])'
0
$ perl -le'print ((localtime(time - 60*60*24*3))[8])'
1
$ export TZ=GMT
$ perl -le'print ((localtime(time))[8])'
0
$ perl -le'print ((localtime(time - 60*60*24*3))[8])'
0

I'm first checking the isDST value of the current day/time (2005-10-31
11:48:00), then of 3 days previous. Then I change timezones to GMT,
and check the two dates again. When in Eastern time, isDST is false
for right now, but true for three days ago, while it's always false
when in GMT.

I think you must start reading

man 3 tzset

to learn how the libc time functions determine the current timezone
*on your system*.

Notice that this is different for different versions of libc, it even
differs between versions of gnu libc. You may have to follow the trace,
if this manpage talks about a "system time zone directory", you still
have to check if that directory exists on your system and has the
required files.

What I get from a very superficial browsing (and that applies only to
Linux and glibc2), is that TZ, if set properly, overrides the link
/etc/timezone -- which by the way is no longer a link, but a copy) --
to the correct file in the system timezone directory. This directory
is /usr/share/zoneinfo on my system.

You can set e.g., TZ=:Africa/Djibouti (notice the ':' ), but that only
works if you have e.g. /usr/share/zoneinfo/Africa/Djibouti.

The advantage of the : notation is that the zoneinfo file has information
about all the random decisions made by the politicians in the past,
changing the rules or dates when dst is in force. It is also easier
to have these files updated automatically when there are new decisions.


-Enrique

 

[David Magda]

And for those who do not follow American politics, the rules in the
U.S. may be changing once again in 2007:

<http://webexhibits.org/daylightsaving/b.html>

FWIW, the provinces in Canada will probably change their rules to
match the US because of how much the two countries are linked
economically.

 

[Bill Marcum]

["Followup-To:" header set to comp.unix.programmer.]

Someone's always got to be different. Like in the U.S. state of
Arizona, where the state as a whole doesn't do DST, but the Navajo
reservation does.

And most of Indiana, but next year they will use DST.

 

[snoopy_]

paul,
You're exactly right. Other scripts I set the TZ specifically, but
in this one it was missing which caused the problem. I use the TZ in
other scripts to catch specific information during certain hours in
logs, but in this script I assumed that perl would be able to tell if
DST was in effect or not, but while in GMT I guess it can't deliver
that information because it's senseless. However, taking your advice
it runs perfectly. Thank you very much.

I have a server that is set to GMT and it needs to interact with
other servers that are not and the other servers also observe daylight
savings time adjustments. I am trying to re-write some scripts that do
not require any changes due to the timechange, I thought I found the
cure via perl's localtime function, but this last weekend showed me
that since my box is set to GMT it doesn't care about DST and perl
won't pick up the change.

Here's what I was using (our code standard is ksh):

chk_dst()
{
DST=`/usr/bin/perl -e '($isdst) = (localtime)[8]; print
"$isdst\n";'`
if [ $DST == 0 ]; then
TIME1=14
TIME2=19
elif [ $DST == 1 ]; then
TIME1=15
TIME2=20
elif [ $DST -ge -1 ]; then
echo "Cannot determine system time" >> /tmp/dstTime.out
fi
}

I was hopping to see a "0" when we are out of DST, and a "1" when we
were in DST. Neither seems to be the case. I also tried setting my
TZ variable to a local time, but I haven't seen any changes. It
appears the issue is that since my box is set to GMT, I won't be able
to use perl to get the DST info. Any suggestions?

Are you sure $TZ didn't affect anything? It seems to for me...
$ echo $TZ
US/Eastern
$ perl -le'print ((localtime(time))[8])'
0
$ perl -le'print ((localtime(time - 60*60*24*3))[8])'
1
$ export TZ=GMT
$ perl -le'print ((localtime(time))[8])'
0
$ perl -le'print ((localtime(time - 60*60*24*3))[8])'
0

I'm first checking the isDST value of the current day/time (2005-10-31
11:48:00), then of 3 days previous. Then I change timezones to GMT,
and check the two dates again. When in Eastern time, isDST is false
for right now, but true for three days ago, while it's always false
when in GMT.

Paul Lalli

 

[snoopy_]

Jordan,
All our servers run on GMT, but some external customers run local
time and some run on CST, PCT, etc... We run a middleware application
that must bend to our customers, so if they expect a file delivered to
them at a certain time, or we need to check a file that they deliver to
use everyday at 3:00PM I need to make the adjustment in our scripts to
look for the file. In the past the team would edit all the files by
hand, every six months. Then you have to know which scripts are
sensitive to the daylight savings changes. My goal was to take those
that were sensitive and build a quick test to see if DST was in effect,
and if so use this time, if not use another time. It really stinks to
run this way, but I didn't have any alternatives.

 

[Alan Coopersmith]

(e-mail address removed) (Gordon Burditt) writes in comp.unix.solaris:
|DST just *ISN'T* "in effect" or "not in effect" for the whole world,
|or even for those parts of the world that use DST. Different countries
|have different rules.

And they don't even go in the same direction once you start dealing with
Northern & Southern hemispheres - Australia starts DST about the time
the US stops.

See http://www.timeanddate.com/time/aboutdst.html for just how complex
DST is.

 

[Bart Lateur]

DST=`/usr/bin/perl -e '($isdst) = (localtime)[8]; print "$isdst\n";'`

I was hopping to see a "0" when we are out of DST, and a "1" when we
were in DST.

Maybe you're being bitten by the standardd boolean false in perl, which
stringifies to "".

And using the -l command line switch (lower case L) will make print add
the newline for you. So this can become:

DST=`/usr/bin/perl -le 'print +(localtime)[8] || 0'`

The "+" is one way to make sure perl doesn't treat just the (localtime)
as the parameters to print.

 

[Robert Bonomi]

Someone's always got to be different. Like in the U.S. state of
Arizona, where the state as a whole doesn't do DST, but the Navajo
reservation does.

It's even *messier* than that --
the State of Arizona doesn't do DST.
The Navajo Nation, part of which lies within Arizona _does_ do DST.
The Hopi Indian Reservation, which lies entirely within the Navajo Nation
doesn't do DST.

Travelling on a _North/South_ line through AZ, you can encounter FIVE areas
where the time is different from surrounding territory.

 

[Richard L. Hamilton]

All our servers run on GMT, but some external customers run local
time and some run on CST, PCT, etc... We run a middleware application
that must bend to our customers, so if they expect a file delivered to
them at a certain time, or we need to check a file that they deliver to
use everyday at 3:00PM I need to make the adjustment in our scripts to
look for the file.

And if you've got one customer in China, one customer in France,
one customer in the USA, one customer in Canada, and one customer
in Mexico, and they all want the file at 3:00PM their local time,
you've got a lot more problems than whether daylight savings time
is in effect, especially if you don't know what time zone your
customers are in.

Your problem is NOT that you need to know whether daylight savings
time is in effect. Your problem is that you need to convert from
one time zone to another. That, of course, requires that you specify
the time zone involved (*NOT* GMT). One way to do this is to set
the time zone to the local time zone of a customer (no way to do
this portably IN C but by POSIX you can set the TZ environment
variable), and have it convert the local time specified by the
customer to GMT (using mktime() ). Repeat daily, weekly, or whatever
to determine the deadline in GMT.[/QUOTE]
[...]

That's why I've long thought that something like rpc.cmsd ought to record
the local time _and_ time zone that events are scheduled in, so that it
can expand repeating events itself in terms of the time zone in which they
were scheduled. Thus, if I schedule a repeating worldwide event in terms
of my local time, it may shift for DST relative to GMT, and may have both
my DST shifts and the viewer's possibly different DST shifts applied to
it before they see it; that's IMO more intuitive behavior than the current,
which is that it only schedules properly if both clients and rpc.cmsd are
running in the same time zone. Of course, they'd still have to stay in
sync on the rulebase that determined base and DST offsets and DST start
and end dates and times for every given timezone that they might deal with.

Until such a client/server calendar scheduling program does something like
that, or until everyone everywhere schedules cross-timezone events in a
single DST-free timezone (like GMT/UTC), there will be unexpected or
undesirable results.