469,936 Members | 2,466 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,936 developers. It's quick & easy.

time zone/daylight savings time help needed

Hey all.

I know with Perl "there's more than one way to do it", but I'd rather
not reinvent the wheel...

/usr/share/zoneinfo/Etc/
contains files like GMT-5 or GMT+8 etc which would be really handy for
me to tweak $ENV{'TZ'} to play with dates and times, but I'm trying to
find the 'best' approach to handle this scenario:

- user adds a meeting time in local time (Pacific time) which is
stored in MySQL
- when another user logs in, they see the time converted to their own
TZ offset, which is configured based on their country
(in the case where their country has multiple TZ's, they are asked
what time it is at their location to help my script determine their
offset relative to UTC)

I have Date::Manip at my disposal, but not sure of the 'best' approach
for handling this work, or if that library is even best suited for
this.

FYI: Server's timezone is set to UTC... figured it was easiest that
way?

My thoughts are this:
- use Date::Manip to see if the current date/time is between 2am on
the first Sunday of April or 2am on the last Sunday of October (1986's
mandated rules for US daylight savings time)
- meeting time/day-of-week is manipulated using Date::Manip's
&ParseDate() subroutine with "+ 7 hours" or "+ 8 hours", accordingly,
and stored in the database (MySQL as DATETIME field type)
- when another user logs in, I know their offset relative to UTC, but
have no 'rules' for determining whether they too are affected by DST
or not, as these users will be world-wide... and that's my roadblock -
if they are affected by DST as well, I need another way to convert the
time/date of the meeting accordingly.

/usr/share/zoneinfo/ may not be useful considering our end users may
not know which zone file to pick from a list if (for example) I just
list all of the files within the /Asia/ folder, and they live in
Moscow, since Moscow is not listed in the /Asia/ folder. (it's listed
in /Europe/ but last time I checked a map, Russia was part of Asia)

So I'm stuck with a user-friendly way of showing my users what time a
meeting is at in their local time since I'm not confident of how best
to determine whether DST affects their TZ offset from GMT.

The other drawback with /usr/share/zoneinfo/Etc/ is that there are no
"half hour" files, such as Newfoundland time in Canada, which is an
extra half hour ahead of Atlantic time.

Any feedback, insight, perldoc references, or example code would be
most welcomed.

-g*****@w98.us
Jul 19 '05 #1
1 7151
go****@w98.us (ian douglas) wrote in message news:<b6**************************@posting.google. com>...
Hey all.

I know with Perl "there's more than one way to do it", but I'd rather
not reinvent the wheel...

/usr/share/zoneinfo/Etc/
contains files like GMT-5 or GMT+8 etc which would be really handy for
me to tweak $ENV{'TZ'} to play with dates and times, but I'm trying to
find the 'best' approach to handle this scenario:
Time::Local::timelocal() and localtime() should honour $ENV{TZ}.
However on some OSs (or rather LIBCs) they don't honour changes in
$ENV{TZ} after the first call.
/usr/share/zoneinfo/ may not be useful considering our end users may
not know which zone file to pick from a list if (for example) I just
list all of the files within the /Asia/ folder, and they live in
Moscow, since Moscow is not listed in the /Asia/ folder. (it's listed
in /Europe/ but last time I checked a map, Russia was part of Asia)


Report bugs to your /usr/share/zoneinfo/ to your OS vendor.

This newsgroup does not exist (see FAQ). Please do not start threads
here.
Jul 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Bathroom_Monkey | last post: by
10 posts views Thread by Marc Pelletier | last post: by
1 post views Thread by Drew | last post: by
5 posts views Thread by ECVerify.com | last post: by
2 posts views Thread by Joshua J. Kugler | last post: by
6 posts views Thread by dredge | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.