Is there a perl package, or data in a form easily used by a perlscript, that can be used to determin

[Ted Byers]

NB: I have seen information about using the system's settings, but
that is not relevant to this problem.

I have a number of DB tables that have datetime values defined WRT UTC
time. If all users could/would work with UTC, there'd be no problem.
I have stored, in a users table, the users' specific timezones. So
far so good. I can use Date::Manip to convert from UTC to each user's
timezone easily. That is great!

However, in many localities, there is a need to switch to and from a
daylight savings time, and I can use the time zones defined in
Date::Manip to specify which users would be using daylight savings
time, but the problem is that using something like "EST5EDT" in either
$from or $to Date_ConvTZ($date1,$from,$to1); does nothing (i.e. the
value returned is identical to $date1). In some respects, I was not
very surprised: unless there was some kind of database hidden in the
bowels of Date::Manip, it couldn't know when to switch to or from
daylight savings time based on the value of $date1. I would not have
a problem creating my own function to do the converstion (dispatching
to Date_ConvTZ using, in the above example, either EST or EDT
depending on the value of the date to be converted), but the problem
is to know when to use EST and when to use EDT (or CET vs CEST, or CST
vs CDT, MST vs MDT, &c.). The date on which the change happens is
different in different time zones (e.g. compare CET#CEST vs EST#EDT).
And I'd need this to be correct even though conventions on use of
daylight savings times are subject to change (as in the US a year or
two back).

So, is there a package that you can recommend that handles this
cleanly, or is there a database/flat data file that can be easily
loaded into an RDBMS such as MySQL, PostgreSQL, MS SQL Server, that I
could use to solve this? I have downloaded and installed a large
number of time related packages using PPM (Activestate Perl 5.10.0 on
Windows XP), but none of the ones I have examined address this
particular issue. I am so frustrated in my search on this that until
I find an adequate solution, the policy we've adopted is to put the
onus on the client to tell us whether or not he wants reports using
daylight savings times, and if so, when the transitions to and from
daylight savings time happens. I would be grateful if someone could
point me to an option that is more user friendly.

Thanks

Ted

 

[J. Gleixner]

NB: I have seen information about using the system's settings, but
that is not relevant to this problem.

Could the subject be a little longer???

I have a number of DB tables that have datetime values defined WRT UTC
time. If all users could/would work with UTC, there'd be no problem.
I have stored, in a users table, the users' specific timezones. So
far so good. I can use Date::Manip to convert from UTC to each user's
timezone easily. That is great!

However, in many localities, there is a need to switch to and from a
daylight savings time, and I can use the time zones defined in
Date::Manip to specify which users would be using daylight savings

[...]

It's saving daylight, so there's only one 's' in daylight saving time.

Lots of help/discussions/people who can help at:

http://datetime.perl.org/

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Ted Byers

However, in many localities, there is a need to switch to and from a
daylight savings time, and I can use the time zones defined in
Date::Manip to specify which users would be using daylight savings
time, but the problem is that using something like "EST5EDT" in either
$from or $to Date_ConvTZ($date1,$from,$to1); does nothing (i.e. the
value returned is identical to $date1). In some respects, I was not
very surprised: unless there was some kind of database hidden in the
bowels of Date::Manip, it couldn't know when to switch to or from
daylight savings time based on the value of $date1.

There is a notion of "timezone". A timezone uniquely determines the
mapping GMT --> local time. "EST5EDT" is not a timezone.

E.g., on this computer, I do

echo $TZ

US/Pacific

It is a function of kernel/CRT library to have a database of
timezones. On capable systems, you should do

$ENV{TZ} = 'US/Pacific';
POSIX::settz(); # sp? tzset()?
print scalar localtime time;

and get the correct local time.

Hope this helps,
Ilya

 

[Ted Byers]

[A complimentary Cc of this posting was sent to
Ted Byers

However, in many localities, there is a need to switch to and from a
daylight savings time, and I can use the time zones defined in
Date::Manip to specify which users would be using daylight savings
time, but the problem is that using something like "EST5EDT" in either
$from or $to Date_ConvTZ($date1,$from,$to1); does nothing (i.e. the
value returned is identical to $date1).  In some respects, I was not
very surprised: unless there was some kind of database hidden in the
bowels of Date::Manip, it couldn't know when to switch to or from
daylight savings time based on the value of $date1.

There is a notion of "timezone".  A timezone uniquely determines the
mapping GMT --> local time.  "EST5EDT" is not a timezone.

True. But Date::Manip uses it as a convention for indicating that the
machine uses both EST and EDT. It works OK when I am working on times
relevant to my local machine. But my current problem is that the
times in question are stored in a database in UTC times, and really
have nothing to do with the timezone that applies to the server
running the DB. It is in the midwest US while the institution that is
the source of the data is in central Europe and we have clients on,
for example, the west coast of the US.

E.g., on this computer, I do

   >echo $TZ
   US/Pacific

It is a function of kernel/CRT library to have a database of
timezones.  On capable systems, you should do

   $ENV{TZ} = 'US/Pacific';
   POSIX::settz();                      # sp?  tzset()?
   print scalar localtime time;

and get the correct local time.

Hope this helps,
Ilya

What you suggest is applicable to various tasks on my own machine, but
actually I already have that working already. My problem involves
converting times that apply to one institution on the other side of
the planet into timezones that are on the other side of this
continent. I don't see how working wih my own local time helps.

Thanks anyway Ilya

 

[Ted Byers]

Could the subject be a little longer???

I could try to get it longer, but my fingers would get too tired. ;-)

I have a number of DB tables that have datetime values defined WRT UTC
time.  If all users could/would work with UTC, there'd be no problem.
I have stored, in a users table, the users' specific timezones.  So
far so good.  I can use Date::Manip to convert from UTC to each user's
timezone easily.  That is great!

However, in many localities, there is a need to switch to and from a
daylight savings time, and I can use the time zones defined in
Date::Manip to specify which users would be using daylight savings

[...]

It's saving daylight, so there's only one 's' in daylight saving time.

Lots of help/discussions/people who can help at:

http://datetime.perl.org/

OK Thanks. I'll take a look there and see what progress I can make.

Thanks

Ted

 

[Dr.Ruud]

Ted Byers schreef:

Ilya Zakharevich:

What you suggest is applicable to various tasks on my own machine, but
actually I already have that working already. My problem involves
converting times that apply to one institution on the other side of
the planet into timezones that are on the other side of this
continent. I don't see how working wih my own local time helps.

Huh? Just put a different timezone string in $ENV{TZ}, right?

 

[Peter Wyzl]

Ted Byers schreef:

Huh? Just put a different timezone string in $ENV{TZ}, right?

Yes but is there some 'authorative source' of what all the different
timezones are and the daylight times for those zones and when they switch
back and forth?

P

 

[RedGrittyBrick]

is there some 'authorative source' of what all the different
timezones are and the daylight times for those zones and when they
switch back and forth?

Since those things are a matter of political whim I doubt there is a
source I would be happy labelling authoritative for the whole planet.

Try
http://www.twinsun.com/tz/tz-link.htm

 

[Dr.Ruud]

Peter Wyzl schreef:

but is there some 'authorative source' of what all the different
timezones are and the daylight times for those zones and when they
switch back and forth?

I use DateTime::TimeZone which uses Olson. Good enough for me.
http://search.cpan.org/search?query=timezone&mode=module

 

[sln]

Since those things are a matter of political whim I doubt there is a
source I would be happy labelling authoritative for the whole planet.

Try
http://www.twinsun.com/tz/tz-link.htm

Its the alias for $GOD

sln

 

[Ted Byers]

Ted Byers schreef:



Huh? Just put a different timezone string in $ENV{TZ}, right?

Actually no. This is to interact with a database on a server that
serves a web application. Messing with the environment settings on
the server for the timezone is guaranteed to fail. For example, there
could be simultaneous requests for data applicable to different
locations. Something like the function Date_ConvTZ($date,$from,$to)
in Date::Manip is required instead but which would make use of the
olson database you mentioned in another post to know when either
timezone should use daylight saving time.

Since you said you use DateTime::TimeZone, can you tell me an example
of how to use it to take a date that, say, ParseDate($string), from
Date::Manip, would return and convert it from one timezone to another
using Olson's database to taking daylight saving time into account (in
effect making something like Date_ConvTZ that would work with the
EST5EDT that Date::Manip uses in other functions).

Thanks

Ted

 

[Ted Byers]

Its the alias for $GOD

sln

That gives you the olson data that Dr Ruud mentioned. I have
downloaded that and am presently trying to figure out how to use it.
found a couple scripts in the timezone project: parse_olson and
update_from_latest_olson. I can't use the latter since it is written
explicitly using programs and paths found on Unix and not, normally,
on Windows, but parse_olson looks like it may work for me. I'll know
later today if it does. But I am still looking through the
documentation for DateTime::TimeZone to see how to use it to convert,
e.g., a time from UTC to "EST5EDT" (as defined in Date::Manip), using
either EST or EDT on the right dates.

Thanks

Ted

 

[Jürgen Exner]

Yes but is there some 'authorative source' of what all the different
timezones are and the daylight times for those zones and when they switch
back and forth?

Impossible. If it were by country then at least you would have a chance.
But there are so many special rules and exceptions, in particular in the
US where even individual counties deviate from their state, not to
mention indian reservations that do or do not, etc, etc. It's just plain
a mess.

jue

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Peter Wyzl

Yes but is there some 'authorative source' of what all the different
timezones are and the daylight times for those zones and when they switch
back and forth?

As I said, your kernel/CRTL should already contain such a database. I
would try to follow links starting with

man tzset

to find a way to query the names of the zones...

Hope this helps,
Ilya

 

[Peter Wyzl]

[A complimentary Cc of this posting was sent to
Peter Wyzl

Yes but is there some 'authorative source' of what all the different
timezones are and the daylight times for those zones and when they switch
back and forth?

As I said, your kernel/CRTL should already contain such a database. I
would try to follow links starting with

man tzset

to find a way to query the names of the zones...

If I wasn't one of the large % of users who don't have a kernel as such,
that might be helpful.

P

 

[Ted Byers]

Peter Wyzl schreef:


I use DateTime::TimeZone which uses Olson. Good enough for me.http://search.cpan.org/search?query=timezone&mode=module

I have downloaded the Olson timezone data, and executed the script
"parse-olson.pl". It created a directory called lib that contains the
timezone data transformed into *.pm files in a number of directories.
I have perl installed in C:\Perl. Do I just copy the files and
folders created by parse_olson.pl into C:\Perl\site, over-writing
what's already there?

Thanks

Ted

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Peter Wyzl

If I wasn't one of the large % of users who don't have a kernel as such,

And who do you think runs your Perl? Maybe the BIOS? ;-)

Anyway, POSIX::tzset will run tzset() function of the CRTL of (your?)
compiler. Its documentation may also contain a list...

(But probably tzset() is very crippled on Win*...)

Yours,
Ilya

 

[Martien Verbruggen]

[A complimentary Cc of this posting was sent to
Peter Wyzl

If I wasn't one of the large % of users who don't have a kernel as such,

And who do you think runs your Perl? Maybe the BIOS? ;-)

Anyway, POSIX::tzset will run tzset() function of the CRTL of (your?)
compiler. Its documentation may also contain a list...

THis is the second time you've used the (presumably) acronym CRTL. What
exactly do you mean by that? I don't know the term, and Google,
Wikipedia freedictionary and the hacker's dictionary also don't seem to
help.

Martien

 

[Martijn Lievaart]

THis is the second time you've used the (presumably) acronym CRTL. What
exactly do you mean by that? I don't know the term, and Google,
Wikipedia freedictionary and the hacker's dictionary also don't seem to
help.

C RunTime Library, aka CRT.

M4

 

[Dr.Ruud]

Ted Byers schreef:

Dr.Ruud:

I have downloaded the Olson timezone data, and executed the script
"parse-olson.pl". It created a directory called lib that contains the
timezone data transformed into *.pm files in a number of directories.
I have perl installed in C:\Perl. Do I just copy the files and
folders created by parse_olson.pl into C:\Perl\site, over-writing
what's already there?

I have no clue what you are trying to achieve, or rather mess up, so I
can't anwer that question.
But if you want to install specific Perl modules on a Windows system in
a clean way, just use the latest ActiveState or the Vanilla Perl tools.