Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

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

by BigLug (Chaplain)
on Oct 09, 2005 at 07:38 UTC ( [id://498529]=note: print w/replies, xml ) Need Help??


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:

  • 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)

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

    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        

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://498529]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (8)
As of 2024-03-28 10:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found