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:
- Firstly there is the sort that you are fixed on: The seconds that have been experienced by an entity traversing through that period (we're calling this UTC math). For this, you want to know that between 9am on one day and 9am the next day there were 86400 seconds (or 82800 or 90000). If you started a long running, timed perl process, you care more about the number of seconds that have elapsed rather than the time on the clock. However here, you'd be in error to divide those seconds by 86400 and call it days. A day, and indeed a minute, can have a varying number of seconds.
- Secondly there is 'Local Math'. This is the time as measured by the clock on your wall. It has nothing to do with the period experienced by an entity, but rather the distance the clock has moved between two moments. This is the sort of math used to determine how many days you have before your tax is due, or that you have to meet the boss every day at the same time, or the average start time of your favorite TV program. It's more about the human side of dates and times
For the first sort of math, DateTime is not needed. Perhaps this is the only sort of date and time calculations you need, in which case, please continue to avoid using any date and time modules that talk about anything other than seconds. On the other hand, if you need the second sort of math, then you're going to need something a little more complex than just calling
time().
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)