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.

Replies are listed 'Best First'.
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!
[reply]

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

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

[reply]
[reply]
Re^4: Adding to a date using Time::localtime
by ikegami (Patriarch) 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.

[reply]
Re^4: Adding to a date using Time::localtime
by scorpio17 (Canon) 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...
[reply]

      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.

[reply]
        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.
[reply]

In Section Seekers of Perl Wisdom