in reply to Re^6: Calculate Age, days to next and days from last for a given birthday
in thread Calculate Age, days to next and days from last for a given birthday

Isn't converting years+months+days into a number exactly what (localtime)[7] does?

No, it only combines month and day, not year, month and day. Without taking the year into account, you need to work around leap years. I didn't have to. You have to, and you did, but incorrectly. (Years divisible by 4 are leap years, except those divisible by 100, except those divisible by 400.)

Actually, it just occured to me that both of our solutions have the following problems: They can't handle dates < Jan 1st 1970 or >= (some point in) 2038. Not very useful.

  • Comment on Re^7: Calculate Age, days to next and days from last for a given birthday
  • Download Code

Replies are listed 'Best First'.
Re^8: Calculate Age, days to next and days from last for a given birthday
by ruzam (Curate) on Apr 29, 2006 at 17:01 UTC
    Again with the leap years...

    As I explained to davidrw, the script as written (both mine and your version) uses current year +/- 1 year, not some arbitrary year in the past or future. At no time is any other year passed into a date function.

    Which means it breaks if you can go back in time to run it before 1970 (which, if you've found a way to do it, please let me know cause there are some investments I'd like to make). It also breaks if you're still using it by 2038, but that's a Perl internal date problem and well beyond the control of this script (and every other Perl script written that uses current date).

    So neither of our scripts will ever have to deal with dates < Jan 1st 1970 or >= (some point in) 2038. Not as written anyway
[reply]
      Not again, still. You asked what was wrong with (localtime)[7], and I told you. You need to handle leap years (contrary to what you said). You attempted to do so, but it's buggy. It's wrong for 1900 and 2100, for starters. You might say that's not a problem because the system doesn't accept those dates, but it's a bug that it can't accept those dates. Once you fix your solution to accepts those dates, you'll have to fix the problem with the year 1900 and 2100. So that's two bugs. You're also off by a day (I think) when you run the program with certain combinations of current time, current date and current timezones for a total of three bugs.
[reply]
[d/l]
        ???

        But I do handle leap years? Just not the year 2100.

        1900 is in the past. It has nothing to do with my script, how it's written or whether it's a leap year. 1900 is the past, is the past, is the past. The only way you can reach it is to roll back you system clock so that your system thinks the current year is 1900 which is far beyond the use or intentions of this script. Do we modify all our scripts to accept the possibility of someone resetting the system clock to some abnormal date?

        It's not a bug that it can't accept those dates? That's not what the script does. There's no argument to accept an arbitrary second date to use. You're suggesting it's a bug that the script doesn't accept something it doesn't use.

        If it's necessary to appease the gods to account for the possibility of this script being used in the year 2100 I'll do it, as unrational as I think that is. To account for 1900 is just plain wrong IMHO.

        I'd like to see an example of off by a day with certain combinations of current time, current date and current timezones.
[reply]

In Section Code Catacombs