Re: Inconsistent bug with delta_ms, add, and time zones
On Tue, 3 Nov 2009, Ronald J Kimball wrote: Dave Rolsky wrote: Sometimes DateTime::TimeZone thinks your local time zone is UTC. I have no idea why it'd would be doing this. You could hack up a local copy of DateTime::TimeZone::Local::Unix and have it spit out everything it's doing and what it finds. Either it's doing something wrong or your system is very oddly configured. I've discovered that, on this system, although /etc/localtime is a copy of /usr/share/zoneinfo/America/New_York, /etc/timezone contains 'Etc/UTC'. I presume that qualifies as an oddly configured system. :) That is a bit weird. I'm not sure why sometimes DateTime::TimeZone::Local would be getting the time zone from /etc/localtime and other times from /etc/timezone, though. Perhaps the call to File::Find::find() in DateTime::TimeZone::Local::Unix::_FindMatchingZoneinfoFile is failing intermittently? That seems unlikely. The order of the checks in DT::TZ::Local is static, and there's no reason the find should fail sometimes and not others. As someone else pointed, does "intermittent" really mean "when run from different environments"? Is it possible that sometimes when the code is run it can't actually read /usr/share/zoneinfo for some reason? -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
RE: Inconsistent bug with delta_ms, add, and time zones
Ugh, I need more caffeine today it seems. Ignore my idiotic path comment. Question of cron vs. non-cron still applies though? If nothing else but to narrow the conditions under which your issue is occurring. Bobby > -Original Message- > From: Metz, Bobby > Sent: Tuesday, November 03, 2009 11:09 AM > To: datetime@perl.org > Subject: RE: Inconsistent bug with delta_ms, add, and time zones > > Ronald, > Do you run the script via cron? If so, do you only see the timezone > error when running it via cron and not when running manually? If yes to > both, then I'd wager the routine you referenced is impacted by the shell > path not being the same for cron as for your login session. I don't know > that module so this is pure speculation but thought that would be easy to > rule out just in case. > > Bobby > > > > -Original Message- > > From: Ronald J Kimball [mailto:rkimb...@pangeamedia.com] > > Sent: Tuesday, November 03, 2009 8:52 AM > > To: Dave Rolsky > > Cc: datetime@perl.org > > Subject: Re: Inconsistent bug with delta_ms, add, and time zones > > > > Dave Rolsky wrote: > > > Sometimes DateTime::TimeZone thinks your local time zone is UTC. I > have > > > no idea why it'd would be doing this. You could hack up a local copy > of > > > DateTime::TimeZone::Local::Unix and have it spit out everything it's > > > doing and what it finds. > > > > > > Either it's doing something wrong or your system is very oddly > > configured. > > > > I've discovered that, on this system, although /etc/localtime is a copy > > of /usr/share/zoneinfo/America/New_York, /etc/timezone contains > > 'Etc/UTC'. I presume that qualifies as an oddly configured system. :) > > > > I'm not sure why sometimes DateTime::TimeZone::Local would be getting > > the time zone from /etc/localtime and other times from /etc/timezone, > > though. Perhaps the call to File::Find::find() in > > DateTime::TimeZone::Local::Unix::_FindMatchingZoneinfoFile is failing > > intermittently? > > > > Ronald
Re: Inconsistent bug with delta_ms, add, and time zones
Dave Rolsky wrote: Sometimes DateTime::TimeZone thinks your local time zone is UTC. I have no idea why it'd would be doing this. You could hack up a local copy of DateTime::TimeZone::Local::Unix and have it spit out everything it's doing and what it finds. Either it's doing something wrong or your system is very oddly configured. I've discovered that, on this system, although /etc/localtime is a copy of /usr/share/zoneinfo/America/New_York, /etc/timezone contains 'Etc/UTC'. I presume that qualifies as an oddly configured system. :) I'm not sure why sometimes DateTime::TimeZone::Local would be getting the time zone from /etc/localtime and other times from /etc/timezone, though. Perhaps the call to File::Find::find() in DateTime::TimeZone::Local::Unix::_FindMatchingZoneinfoFile is failing intermittently? Ronald
RE: Inconsistent bug with delta_ms, add, and time zones
Ronald, Do you run the script via cron? If so, do you only see the timezone error when running it via cron and not when running manually? If yes to both, then I'd wager the routine you referenced is impacted by the shell path not being the same for cron as for your login session. I don't know that module so this is pure speculation but thought that would be easy to rule out just in case. Bobby > -Original Message- > From: Ronald J Kimball [mailto:rkimb...@pangeamedia.com] > Sent: Tuesday, November 03, 2009 8:52 AM > To: Dave Rolsky > Cc: datetime@perl.org > Subject: Re: Inconsistent bug with delta_ms, add, and time zones > > Dave Rolsky wrote: > > Sometimes DateTime::TimeZone thinks your local time zone is UTC. I have > > no idea why it'd would be doing this. You could hack up a local copy of > > DateTime::TimeZone::Local::Unix and have it spit out everything it's > > doing and what it finds. > > > > Either it's doing something wrong or your system is very oddly > configured. > > I've discovered that, on this system, although /etc/localtime is a copy > of /usr/share/zoneinfo/America/New_York, /etc/timezone contains > 'Etc/UTC'. I presume that qualifies as an oddly configured system. :) > > I'm not sure why sometimes DateTime::TimeZone::Local would be getting > the time zone from /etc/localtime and other times from /etc/timezone, > though. Perhaps the call to File::Find::find() in > DateTime::TimeZone::Local::Unix::_FindMatchingZoneinfoFile is failing > intermittently? > > Ronald
Re: Inconsistent bug with delta_ms, add, and time zones
Dave Rolsky wrote:
On Fri, 23 Oct 2009, Ronald J Kimball wrote:
I have a subroutine that uses two DateTime objects. It calls
delta_ms() to get the delta between the two objects, does a bit of
math, then calls add() to add the delta to one of the objects.
Although both objects are created with time_zone => local,
occasionally the result is 4 hours ahead of what I expect (which would
correspond to UTC).
Can you break this down to a _much_ smaller example that demonstrates
the problem (ideally, just 2-4 lines)? I'm too lazy to wade through all
the irrelevant code here.
That's fair. Unfortunately, I haven't been able to reproduce the
problem outside the actual application. However, I added some logging
and got some additional info.
When I get the wrong result, the first DateTime object has its time zone
set to UTC, rather than to America/New York (my local time zone).
The object is created like so:
my %tmp;
@tmp{qw/ year month day hour minute second /} =
$current_delivery_date =~ /(\d+)/g;
my $dt = DateTime->new(%tmp, time_zone => 'local');
Then, I check the name of the time zone with:
$dt->time_zone->name
and sometimes it's UTC.
Do you have any guesses as to why this could be happening?
Here's the version info I forgot to include originally:
DateTime 0.50
DateTime::TimeZone 0.90
perl 5.10.0
OS Ubuntu Hardy x64
thanks,
Ronald
Re: Inconsistent bug with delta_ms, add, and time zones
On Mon, 2 Nov 2009, Ronald J Kimball wrote:
When I get the wrong result, the first DateTime object has its time zone set
to UTC, rather than to America/New York (my local time zone).
The object is created like so:
my %tmp;
@tmp{qw/ year month day hour minute second /} =
$current_delivery_date =~ /(\d+)/g;
my $dt = DateTime->new(%tmp, time_zone => 'local');
Then, I check the name of the time zone with:
$dt->time_zone->name
and sometimes it's UTC.
Do you have any guesses as to why this could be happening?
Sometimes DateTime::TimeZone thinks your local time zone is UTC. I have no
idea why it'd would be doing this. You could hack up a local copy of
DateTime::TimeZone::Local::Unix and have it spit out everything it's doing
and what it finds.
Either it's doing something wrong or your system is very oddly configured.
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
Re: Inconsistent bug with delta_ms, add, and time zones
On Fri, 23 Oct 2009, Ronald J Kimball wrote: I have a subroutine that uses two DateTime objects. It calls delta_ms() to get the delta between the two objects, does a bit of math, then calls add() to add the delta to one of the objects. Although both objects are created with time_zone => local, occasionally the result is 4 hours ahead of what I expect (which would correspond to UTC). Can you break this down to a _much_ smaller example that demonstrates the problem (ideally, just 2-4 lines)? I'm too lazy to wade through all the irrelevant code here. Also, since this probably time zone related and we probably don't share your local time zone, please set the zone explicitly in your example code. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Inconsistent bug with delta_ms, add, and time zones
I'm experiencing some very odd behavior with DateTime, which I'm at a
loss to understand...
I have a subroutine that uses two DateTime objects. It calls delta_ms()
to get the delta between the two objects, does a bit of math, then calls
add() to add the delta to one of the objects. Although both objects are
created with time_zone => local, occasionally the result is 4 hours
ahead of what I expect (which would correspond to UTC).
Suppose the current date/time is 2009-10-23 13:15:43.
I call next_delivery_date('2009-10-23 13:15:00', 'every 1 minutes').
I would expect to get back '2009-10-23 13:16:00'. However, sometimes, I
get '2009-10-23 17:16:00' instead, four hours in the future.
Here's the code (minus the handling for other schedule formats):
sub next_delivery_date {
my ($current_delivery_date, $schedule) = @_;
my %tmp;
@tmp{qw/ year month day hour minute second /} =
$current_delivery_date =~ /(\d+)/g;
my $dt = DateTime->new(%tmp, time_zone => 'local');
# determine the date/time for the next delivery,
# based on the existing delivery date/time and the schedule
my ($quantity, $unit);
if ($schedule =~ /^every (\d+) ([a-z]+)\z/) {
# at the specified duration
($quantity, $unit) = ($1, $2);
} else {
die "Unrecognized delivery schedule '$schedule'";
}
my $now = DateTime->now(time_zone => 'local');
# jump ahead rather than doing repeated adds,
# in case the current delivery date is far in the past
my $delta = 0;
if ($unit eq 'minutes') {
$delta = $now->delta_ms($dt)->{$unit};
} elsif ($unit eq 'days') {
$delta = $now->delta_days($dt)->{$unit};
}
my $add = 0;
if ($delta > $quantity) {
$add = $delta - ($delta % $quantity);
}
$dt->add($unit => $add);
# make sure the new delivery date is in the future
while ($dt < $now) {
$dt->add($unit => $quantity);
}
$dt->set(second => 0);
return $dt->ymd . ' ' . $dt->hms;
}
Some background on the program: I have various delivery events that
happen on specific schedules, such as 'every 1 minutes' or 'daily
08:00'. My program runs as a daemon, checking for delivery events that
need to be run. For each one, it forks off a child process. The child
process runs the delivery event, then calculates the next date/time that
event should be run.
Anyone have any ideas what could be causing this?
Ronald
