Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^3: Adding to a date using Time::localtime

by kyle (Abbot)
on Feb 21, 2007 at 20:13 UTC ( #601420=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Adding to a date using Time::localtime
in thread Adding to a date using Time::localtime

not all days are the same length.

Please explain!

Are you talking about a Leap_second? If Wikipedia is to believed, there have been 23 leap seconds since 1972. Since the OP is only trying to find what date is 14 days into the future, sweetblood's method is only going to have a problem on one second of a day with a leap second. That is, 23 out of the last 1093273318 seconds, as I write this, or one in 47.5 million (y'know, approximately).

I routinely say $ONE_DAY = 24 * 60 * 60. Maybe I'm sloppy, or I just haven't ever written an application where it matters. I suspect if I ever had a problem, I didn't notice or didn't care.


Comment on Re^3: Adding to a date using Time::localtime
Download Code
Re^4: Adding to a date using Time::localtime
by jasonk (Parson) on Feb 21, 2007 at 20:23 UTC

    You will also have issues on days when daylight savings time changes, when one day is either 26 or 23 hours, depending on which way you went...


    We're not surrounded, we're in a target-rich environment!

      You will also have issues on days when daylight savings time changes

      Ah, good point. I figured I had to be missing something. Thanks!

Re^4: Adding to a date using Time::localtime
by ikegami (Pope) on Feb 21, 2007 at 21:17 UTC

    In places with Daylight Saving Time, some days are longer and some are shorter. That's why I used timegm+gmtime (rather than timelocal+localtime) to normalize the date, even though it's a local date.

Re^4: Adding to a date using Time::localtime
by scorpio17 (Monsignor) on Feb 21, 2007 at 21:19 UTC
    I think he means that if the 14 day interval happens to span the day that daylight-savings-time goes 'on' or 'off', then there will be an error (time difference) of one hour. Hypothetically, if you did this calculation around midnight of the day DST kicked in, you might get the wrong result...

      there will be an error (time difference) of one hour.

      Not quite. The result is sometimes a day off. There are no hours in the output, so I don't know how it can be an hour off.

      During one hour of the year, the returned date will be only 13 days away, and
      during another hour of the year, the returned date will be 15 days away.

        Right - I should have said, "there will be an error of one hour in the computed 14 day offset. That is, when you convert 14 days into seconds, it might off by +/-1 hour depending on DST. This will, in turn, cause the final result to be off by a day, as you said.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://601420]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2014-11-01 03:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (227 votes), past polls