in reply to Re^3: Data: Dates, a DateTime replacement to perlfaq4 (TZ nit)
in thread Data: Dates, a DateTime replacement to perlfaq4
You could almost make a case for 'days', if you want to claim that a 24-hour duration should not be reported as 'one day' if it crossed a DST transition.
tye, thanks for this discussion. It follows closely along the lines of something we've been realising in the DateTime mailing list, and is important for anyone dealing with dates and times to realise: There are two kinds of math that deal with datetimes:
But most of the time my preference would be to calculate durations in 'days' as simply 24-hour periods, no matter what the clock might read due to DST transitions or physical movement between timezones.
Well please stop it. A day is not 86400 seconds. Saying a process took 1 day because it took 86400 seconds is just wrong.
Lets imagine that some process takes exactly 86400 seconds, you tell your boss that it takes 1 day. He decides to run that process every day so that it completes at 9am, so therefore, according to you, it needs to start one day earlier at 9am. Now one day, due to daylight savings, this job does not complete until 10am, there are angry customers on the phone and the boss wants you in his office for a meeting.
But please explain how timezones change 60 seconds from being 1 minute or how timezones make a meaningful difference in something that would be reported in terms of 'months'.
I've updated the post you were replying to so that it now reads that you need something more complex than time(), time zones don't matter for a 60 second event, however you do need something that can handle a leap second (which could be your OS, but could be DateTime)
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^5: Data: Dates, a DateTime replacement to perlfaq4 ('day')
by tye (Sage) on Oct 09, 2005 at 15:20 UTC |