|
kanwisch has asked for the wisdom of the Perl Monks concerning the following question:
Ok, I've read the two threads in this forum on this subject ( 170223 and 39564), and I don't think they've answered (at least clearly enough for my lowly understanding) if it's possible to tell when daylight savings time is occurring in some given time zone.
Here's the problem. I, sadly, live in Indiana, where we do not observe daylight savings time. To do a reconciliation process, we must match records with Verisign in California, where they do recognize daylight savings. So, I need my programs to know when California has shifted and appropriately alter the time depending on the time of year so that our daily reports' time range matches midnight to midnight in California. Make sense? And so, by extension, my problem isn't doing the shift (that's trivial), but figuring out WHEN I need to make the hour shift.
Is there a programmatic way to know when daylight savings is currently being observed? If so, can you please give me a hint to understand how to go about it? Is there a Perl module I've overlooked that can tell this kind of information? Looking at the Net:ICal:Daylight module doesn't really help, but if someone knows that will solve the problem, I'll invest a much greater amount of time into understanding the bunch of OO-like modules involved.
TIA, as always, for your experience.
20030208 Edit by Corion : Changed node ids to links |
Re: Daylight Savings Time twist
by BigLug (Chaplain) on Feb 06, 2003 at 22:57 UTC
|
Take a look at DateTime its only a developer release at the moment, but its moving ahead fast. I imagine the people at the DateTime project would like to hear how it goes for you (email datetime@perl.org).
DateTime aims to be the difinitive perl module for working with dates and times. The DateTime::Timezone module(s) are based on the OlsenDB - the central source of information on timezones and daylight savings so they should be right. There is talk on the list about how to keep these files up to date - which will be sorted out by the time you'd need to update them :)
Try using DateTime something like this:
my $realtimehere = DateTime->now;
my $realtimethere = DateTime->new(time_zone => 'America/Los_Angeles');
my $difference = $realtimehere - $realtimethere;
The PODumentation will explain how to use the $difference duration. Also note that you might have to feed a time into the new() method, but I'm sure someone else will chime in and tell you.
The code is completely untested because I can't install DateTime on my mac here at the moment. Of course, read the documentation and then test it :) | [reply]
[d/l] |
|
|
OK, we've had a talk about it and this is the best solution at the moment using the current state of the module:
use DateTime;
%OurLogs = get_the_time_from_the_log_file_as_a_hash();
$here = DateTime->new( time_zone => 'America/Indiana',
map { $_ => $OurLogs{$_} }
qw( year month day hour minute second ) );
$there = DateTime->new( time_zone => 'America/Los_Angeles',
map { $_ => $here->$_() }
qw( year month day hour minute second ) );
Then you can play around with however you want to format the $here and $there objects. Check the PODumentation for details. | [reply]
[d/l] |
|
|
Once again, I have posted the wrong solution. The above solution will give you a time difference if you subtract here from there. However to get the equivlent there time for a particular here time, do this:
use DateTime;
%OurLogs = get_the_time_from_the_log_file_as_a_hash();
$here = DateTime->new( time_zone => 'America/Indiana',
map { $_ => $OurLogs{$_} }
qw( year month day hour minute second ) );
$there = $here->clone;
$there->set_time_zone('America/Los_Angeles');
This will give you the equivlent time in LA for the time in Indiana. Please note that you should set the timezones to appropriate values :)
Many appologies for all the confusion. I woke up at about 3am in a cold sweat realising that I'd posted the wrong solution :) | [reply]
[d/l] |
|
|
Re: Daylight Savings Time twist
by atcroft (Abbot) on Feb 06, 2003 at 20:51 UTC
|
Just a thought, but could you not convert the date/time information for both locations to GMT then convert back to the other? Since GMT is not influenced by daylight savings time, and the timezone information you are using for both locales would likely handle the local influence of GMT, it might be a way to resolve the issue.
Just a thought, though-perhaps someone else can develop the thought, or suggest a better alternative.
Update: After reading your response, I thought about the use of Date::Manip, but noted that it mentioned concerns in dealing with daylight and standard time conversions. However, you can find when the time changes, according to the details located at http://webexhibits.org/daylightsaving/b.html. According to it, daylight savings time begins on the first Sunday of April, and ends on the last Sunday of October. Hope this information might help out.
| [reply] |
|
|
Interesting, but how can I convert the "destination" (CA in this case) time to GMT if I don't know whether it's using Daylight savings at that time or not?
For example, if I localized the $ENV(TZ)="PST" or "PDT", how do I know which one to set it to?
| [reply] |
|
|
Wow, all excellent suggestions. We'll head, I think, into the module first to give a little support to the new extension and certainly provide the writer/team feedback. Failing that, though, I greatly appreciate all the other comments; there are several possibilities I didn't even knew existed!
Vive le Perlmonks!
kanwisch
| [reply] |
Re: Daylight Savings Time twist
by hossman (Prior) on Feb 07, 2003 at 00:00 UTC
|
The best advice I can give anyone when dealing with Date/Time issues is to remember that a "date" (or a "time") is an abstract moment in space/time ... it doesn't matter whether you are in California, or Indiana; it doesn't matter if you observe Daylight Savings time or not; that moment is the same all over the galaxy.
When you describe that moment in text, or in speech, your description inherently takes into account a "base moment" -- just as if you were describing a physical location and you said it was "20 feet up, and 30 feet west", there is some implicit orrigin in your coordinate space that you are speaking relative to.
When you write the text "June 5th, 2003 at 9:36AM" you are describing a moment in time that assumes:
- A Specific type of Calender
- A Base moment that caledner starts at
- the length of a second/minute/etc..
Many of these things are accepted by convention. people assume you are using the Gregorian calender unless you tell them otherwise, they assume you are using standard month names, and standard lengths of a "second" .. but what they don't know is what origin you are using, and what time zone you are using ... that information should be spelled out in your expression of the moment in time as a string.
In your specific case, I would want the API provided to me by the other servers I deal with to make sure that the time is expressed in a format that includes the TimeZone, so I could know without a doubt what they mean.
| [reply] |
Re: Daylight Savings Time twist
by tall_man (Parson) on Feb 06, 2003 at 22:02 UTC
|
| [reply] |
Re: Daylight Savings Time twist
by Enlil (Parson) on Feb 06, 2003 at 21:52 UTC
|
This might or might not help.-enlil | [reply] |
Re: Daylight Savings Time twist
by jonnyfolk (Vicar) on Feb 06, 2003 at 22:09 UTC
|
I don't know much about it but from what you say your server time is constant so you only need to look out for variations in Californian time. What about writing a script as a cron job to check on Californian time (eg a daily visit to worldtimeserver.com set to return a value when the difference is constant, and another value when the difference differs by one hour? The different value can be taken account of by your daily reports and all should be well!
Of course a totally unperlish way of doing this would be to rent (or use free) server space in California and set up regular communications between servers to gauge the difference!
| [reply] |
Re: Daylight Savings Time twist
by cacharbe (Curate) on Feb 07, 2003 at 14:10 UTC
|
I needed to write a similar service for our intranet to list the time at different installations world wide, knowing only their offset from UTC and whether or not they observe DST. DST occurs at the same time everywhere in the US, if it is observed.
I decided to just use one of the NIST time servers and a file with the offset, bool data
You can get the data by making a simple tcp call to the time server, which returns a string that you can split and compute the current time if you know the UTC off set.
Some more DST information, including what US territories, states and holdings acknowledge it.
C-.
---
Flex the Geek
| [reply] |
|
|
