[sf-perl] Getting the timezone

[David Alban]

On 11/17/06, Michael Friedman <friedman at highwire.stanford.edu> wrote:
> Well, now that you've got us all curious as to why you can't use
> modules...

I'm writing a module and, at this moment in time, I want it not to
have dependencies other than core perl itself.  ("Core perl" would
have been a better phrase to have used than "pure perl".)  I may need
to deploy it at work on systems on which I don't have root, and I want
using it to be as simple as:

  use lib "/path/approriate/to/my/module";

  use my::module;

where /path/appropriate/to/my/module can be a non-system location.

> You forgot to divide $difference by 60 to get minutes, but other than
> that this should be OK. Not the easiest way, I'm sure, but it should
> work.

Doh!  Thanks.

> You realize that you are assuming that the server already knows what
> timezone it's in. If it didn't, it would (probably) give you the same
> value for gmtime as localtime.

My module will be noting the time at which events occur.  It doesn't
matter to me in which time zone the machine is, as long as the
timestamps I'm using to record events indicate the correct time zone.
If I get the same value for gmtime as localtime, no problem, the time
zone of the timestamps will be +0000.

I'm trying to get around the ambiguity of timestamps that don't
include the time zone.  Most of the time you might get away with
assuming the time zone is your geographic area's time zone.  But you
can't depend on it.  At one of my gigs, Central Time was the standard
on our machines rather than Pacific Time.  At the current gig, GMT is
the standard.

Why don't I just assume all times are GMT?  Someone could forget to
configure the machine to GMT.  Someone could accidentally set it to
some other random time zone.

My module will call the time zone routine when it starts, and will
cache the value.  Subsequent calls to the routine will check for, and
use any cached value in favor of computing the offset again.

> And if the server is at all unix-like,
> you can get that timezone as
>         $ENV{TZ}

Setting this variable will indeed have the effect of setting the time
zone.  But you can't rely on it being set.

On a fedora box and on an os x box, TZ is unset.  Even if it was, I'd
still need to convert from something like PST8PDT to -0800.  I'd
rather not try to generate a table for all symbolic representations of
time zones.

My module could explicitly set the timezone, but I want to generate
timestamps in the timezone of the host, whatever it may be, rather
than hard coding a time zone.  And if I let the user choose a time
zone, I want to have a default in case the user chooses not to choose.
 The time zone setting of the current host would be that time zone.

> formatted as readable text or
>         system('date +%z');
>
> which even formats it in RFC-2822 format like you want it.

Yes, this is indeed the format I want.  However, I don't want to spawn
a shell and add an extra process.  I generally don't like using
system() or qx{} if I can avoid doing so.

> (The system call will definitely be slower, but also smaller and more
> readable.)

I usually comment my code quite well.  My bad for sending uncommented
and only minimally tested code to the list.  In my defense, it was a
Friday evening and I wanted to go home. :-)

Besides, Tatsuhiko's post shows how I can simplify some unnecessarily
complicated code.

-- 
Live in a world of your own, but always welcome visitors.