Re^3: Data: Dates, a DateTime replacement to perlfaq4 (TZ nit)

Thank you for pointing out that additional feature that the module provides. But you don't need to know when the change-over happens in order to make accurate calculations with dates and that was your original justification for mentioning this feature. So I stand by my claim that your original statement was misleading.

However, if you later want to turn that duration into non-second data (eg. days and months, or even minutes), then you need time zone handling.

No. 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. 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. And such calculations would be about comparing two date-times, and are actually impossible if you just have a duration. So a duration based on epoch seconds just plain doesn't involve timezones.

If you instead convert both epoch second values into date-times in specific timezones and want to compare those instead of calculating the duration between them, then timezones clearly matter.

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

Surely you aren't claiming that if I start an activity 30 seconds before a DST change and finish 30 seconds after it, that I should report the duration as either 61 minutes or as -59 minutes? Or perhaps you want to make the claim that a leap second during that period means that the duration was 1 minute and 1 second (or is that 1 second less than 1 minute?). That would also be wrong, though not as obviously so.

- tye

Comment on Re^3: Data: Dates, a DateTime replacement to perlfaq4 (TZ nit)

Replies are listed 'Best First'.
Re^4: Data: Dates, a DateTime replacement to perlfaq4 (TZ nit) by BigLug (Chaplain) on Oct 09, 2005 at 07:38 UTC
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)	[reply] [d/l] [select]
Re^5: Data: Dates, a DateTime replacement to perlfaq4 ('day') by tye (Sage) on Oct 09, 2005 at 15:20 UTC
Get over it. 'Day' is a perfectly reasonable way to express '24 hours' or however many layers you want to digress through. 'Day' can also mean from midnight to midnight (or perhaps closer to from 4am to 4am when talking about perceived days not statutory days) or just from around dawn to around dusk or how long it takes a planet to rotate. Even less common is using 'day' to mean 'from time X to the next time X', which you appear fixated on claiming as the only valid definition of 'day'. Just look in a dictionary and you're likely to see many mentions of "24-hour" and I doubt you'll find any mention of what you've defined. The scenario you paint to justify your definition is quite strained but also illustrates an important point. Using 'day' for duration implies relative imprecision. No one would jump from 'takes a day' to 'takes exactly 24.0 hours'. The fact that sometimes Sunday lasts 23 or 25 hours isn't a big deal for normal folk. But I find it makes more sense to realize that sometimes Sunday isn't quite a full day in duration and sometimes it is a bit more than one day in duration. Sure, it is still exactly one Sunday. But 'day' doesn't have only one meaning. Sunday is one statutory day, but is not exactly one planetary rotation (a 'day') and sometimes isn't 24 hours (a 'day' in duration). Similarly, sometimes it takes more/less than one minute for the clock to go from 12:00 to 12:01. The clock reading doesn't define the duration known as 'one minute'. One minute is simply 60 seconds. If I move the hands on the clock around for whatever reason, it doesn't cause 'one minute' to become longer or shorter. - tye	[reply]