Welcome to WebmasterWorld Guest from 54.87.18.165

Forum Moderators: coopster & jatar k & phranque

Message Too Old, No Replies

localtime() suddenly adding up to wrong date

     
4:45 am on Feb 28, 2018 (gmt 0)

Senior Member

WebmasterWorld Senior Member 5+ Year Member Top Contributors Of The Month

joined:Mar 15, 2013
posts: 1024
votes: 96


This is the dangdest thing.

I've had this same code running for about 10 years, to determine 14 days from today:

$duration = 14;
$expiration = 0;

# blah blah blah

if (!$expiration) {
$expiration_time = time + ($duration * 86400);
($expire_sec, $expire_min, $expire_hour, $expire_day, $expire_mon, $expire_year, $expire_wday) = localtime($expiration_time);

$expire_month = $expire_mon + 1;
$expire_year += 1900;

$expiration = sprintf("%d%02d%02d", $expire_year, $expire_month, $expire_day);
}


(in retrospect, I don't know why I assign $expire_mon and $expire_month separately like that, I should just use $expire_month and then $expire_month++... but like I said, I wrote it forever ago so God knows what I was thinking or preparing for)

So in the end, $expiration should be a format like 20180313, which would be 14 days from 20180227 (today).

But for the last week or so, at around 11pm it's suddenly advancing 15 days instead of 14! It's as if the server thinks that the time is changing an hour earlier than it is...

... but it's not. I have another script that shows posts with the current server time, and that time is correct. And when I SSH in and use date, it shows the correct time. So the flaw is happening somewhere with time or localtime.

Why it suddenly started happening recently, I have no idea. Unless there was an automated server update or something that's changed something? I'm running CentOS 6.9 xen hvm.

Do you guys see what could be causing this flaw?
12:49 pm on Feb 28, 2018 (gmt 0)

Administrator

WebmasterWorld Administrator phranque is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

joined:Aug 10, 2004
posts:11613
votes: 195


localtime has the same range as gmtime, but because time zone rules change, its accuracy for historical and future times may degrade but usually by no more than an hour.

source: http://perldoc.perl.org/perlport.html#localtime

i would try doing the math in GMT and convert to local.
there are a few CPAN modules that might also be helpful.

Do you guys see what could be causing this flaw?

any system or software updates on the server?
(either installed 2 weeks ago or before the server was rebooted 2 weeks ago?)
8:13 pm on Feb 28, 2018 (gmt 0)

Senior Member

WebmasterWorld Senior Member 5+ Year Member Top Contributors Of The Month

joined:Mar 15, 2013
posts: 1024
votes: 96


there are a few CPAN modules that might also be helpful.
I googled before I posted, and it seems like everyone is suggesting using a module to advance a few days. That seems like overkill to me, and I always worry that it's going to slow down the script unnecessarily to load a module for a single purpose that can be done without it... but if localtime() loses its accuracy then I might have to :-(

any system or software updates on the server?
Nothing intentional, but I have updates set to install "stable" versions automatically so it's possible. I don't see anything outstanding in the logs, though, but that's not necessarily definitive.

The last server reboot was 52 days ago, though, and I'm pretty sure that any system updates would have caused a reboot, right?
1:49 am on Mar 1, 2018 (gmt 0)

Administrator

WebmasterWorld Administrator phranque is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

joined:Aug 10, 2004
posts:11613
votes: 195


The last server reboot was 52 days ago, though, and I'm pretty sure that any system updates would have caused a reboot, right?

not necessarily,,,
6:06 am on Mar 1, 2018 (gmt 0)

Senior Member

WebmasterWorld Senior Member 5+ Year Member Top Contributors Of The Month

joined:Mar 15, 2013
posts: 1024
votes: 96


In retrospect, this is the code I use with the other script that determines the current date and time:

($sec, $min, $hour, $day, $mon, $year, $wday) = (localtime(time))[0..6];
$month = $mon + 1;
$year += 1900;

$today = sprintf("%d%02d%02d", $year, $month, $day);


But it's accurate, so I'm at a loss. It uses both localtime() and time(), just like the flawed script.

I was hoping you guys would see a glaring mistake, but in comparing both I just can't see any reason for it. Literally the only difference is that in one I add ($duration * 86400) to time, and there's just no reason for that to be off by an hour at 11pm.

All I know to do is spend some time finessing the function and break it down line-by-line between 11pm and midnight tomorrow. If I still can't find it, I'll have to rebuild using a module, I guess.

>:-(
9:29 am on Mar 1, 2018 (gmt 0)

Senior Member from GB 

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month

joined:Aug 13, 2003
posts: 1053
votes: 3


Are you in a country (or your settings in a country) where the clocks go forward or backwards an hour in the next couple of weeks?

If so, you might be adding on the number of days (in seconds) and the clocks are being adjusted during this calculation to what the time will be, taking into account this clock adjustment.
6:24 pm on Mar 1, 2018 (gmt 0)

Senior Member

WebmasterWorld Senior Member 5+ Year Member Top Contributors Of The Month

joined:Mar 15, 2013
posts: 1024
votes: 96


Ahhhh, that's a darn good point! I'm in the US, and for us "Daylight Savings Time" begins on March 11 ("Spring forward"). So you're right, it IS possible that it's adding that in ahead of time.

So shoot, maybe localtime() was smarter than me on this one!