On Thu, Mar 1, 2012 at 8:26 PM, Michael G Schwern <[email protected]> wrote: > On 2012.3.1 2:14 PM, [email protected] wrote: >> If the date for $dt is 20120229, the following produces an error! >> >> $dt->set_year($dt1->year + 1); >> >> Invalid day of month (day = 29 - month = 2) > > This error is correct, there is no Feb 29, 2013. > > It could return March 1, 2013... but then adding a year to Feb 29, 2012 and > adding a year and a day give the same result which doesn't make sense. > > It does present a problem... how do you reliably say "same date next year"? > You can't add 365 days because that falls afoul of the leap year problem. If > you asked a human "let's schedule for the same day next year" you'd have to > ask if they meant Feb 28th or March 1st. So I think throwing an exception is > the right thing to do. The application can catch it and ask the user for > clarification.
In theory you're right. In practice, I don't agree. The reason why you're wrong is because nobody is ever going to think of testing whether they are saying "same time next year". So software goes through development, QA, and into production. Then every 4 years stuff randomly crashes with exceptions nobody has ever thought of, often after the original programmer has left. Silently saying "Feb 28th, 2013" may theoretically not be perfect, but it will lead to more reliable software.
