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
In reply to Re^3: Data: Dates, a DateTime replacement to perlfaq4 (TZ nit)
by tye
in thread Data: Dates, a DateTime replacement to perlfaq4
by BigLug
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |