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

No, not all days have 86400 seconds. (Update: Specifically, in places with Daylight Saving Time, some days are longer and some are shorter. The parent's code will result in the calculated date being off by a day when executed during certain hours of the year. )

If you were limited to core Perl, you'd could do something like the following: 

use POSIX       qw( strftime );
use Time::Local qw( timegm_nocheck );

# Get date.
my ($y, $m, $d) = (localtime())[5, 4, 3];
$m += 1;
$y += 1900;

# Add to date.
$d += 14;

# Canonize date.
($y, $m, $d) = (gmtime(timegm_nocheck(0,0,0, $d, $m-1, $y)))[5, 4, 3];
$m += 1;
$y += 1900;

print(strftime("%x", 0,0,0, $d, $m-1, $y-1900), "\n");

[download]

Note: I like keeping $y, $m and $d as a human readable numbers. You could shorten the above by leaving $m 0-based and $y 1900-based.

Note: I don't recommend this approach. Take a minute to install one of the date modules.

Replies are listed 'Best First'.
Re^3: Adding to a date using Time::localtime
by kyle (Abbot) on Feb 21, 2007 at 20:13 UTC

    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.

[reply]
[d/l]

      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]

      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]
      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]

In Section Seekers of Perl Wisdom