http://www.perlmonks.org?node_id=601410


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

Try:
print scalar localtime (time + (86400 * 14));
HTH

Sweetblood

Replies are listed 'Best First'.
Re^2: Adding to a date using Time::localtime
by ikegami (Patriarch) on Feb 21, 2007 at 19:46 UTC

    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");

    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.

      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.

        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!

        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.

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