Re: simpler increment of time values?

Discussion in 'Python' started by Chris Angelico, Jul 5, 2012.

  1. On Thu, Jul 5, 2012 at 11:18 PM, Vlastimil Brom
    <> wrote:
    > Yes, the calculations with seconds since the Unix epoch is very
    > convenient for real times, but trying to make it dateless seemed to
    > make it more complicated for me.
    >
    > The expected output for the increments asked by Jason was already
    > correctly stated by Devin; i.e.: 12:45 plus 12 hours is 0:45 and 12:45
    > minus 13 hours is 23:45.


    I'm not familiar with the Python classes (I tend to think in terms of
    language-agnostic algorithms first, and specific libraries/modules/etc
    second), but if you're working with simple integer seconds, your
    datelessness is just modulo arithmetic.

    time1 + time2 --> (time1 + time2) % 86400
    time1 - time2 --> (time1 + 86400 - time2) % 86400

    Or alternatively, bounding afterward:

    if time > 86400: time-=86400
    if time < 86400: time+=86400

    (The "magic number" 86400 is a well-known number, being seconds in a
    day. Feel free to replace it with 24*60*60 if it makes you feel
    better; I'm pretty sure Python will translate it into a constant at
    parse time. Or alternatively, have a module-level constant
    SECONDS_IN_A_DAY = 86400, in case that number should ever change.)

    ChrisA
    Chris Angelico, Jul 5, 2012
    #1
    1. Advertising

  2. On Thu, 05 Jul 2012 23:56:37 +1000, Chris Angelico wrote:

    > (The "magic number" 86400 is a well-known number, being seconds in a
    > day.


    Does that include leap seconds?


    > Feel free to replace it with 24*60*60 if it makes you feel better;
    > I'm pretty sure Python will translate it into a constant at parse time.
    > Or alternatively, have a module-level constant SECONDS_IN_A_DAY = 86400,
    > in case that number should ever change.)


    "In case"?

    The number of seconds in a day (true solar day) varies by between 13 and
    30 seconds depending on the time of the year and the position of the sun.

    The mean solar day fluctuates randomly by about 5ms due to friction
    between the core and the mantle; it is also systematically slowing due to
    tidal friction. The 2004 Indian Ocean earthquake reduced the length of a
    day by about 3ms; the 2011 Japan earthquake slowed it down by about 2ms.
    Apart from these random changes, there are systematic changes of the
    order of 1ms per year, so in a mere thousand years, the length of the
    mean solar day will be about a second longer.

    Imagine how much extra work we'll be able to get done!

    The stellar day (Earth's rotational period relative to the distant stars)
    is slightly more than 86164.098 seconds; the sidereal day is slightly
    more than 86164.090 seconds. Both are approximately 3 minutes 56 seconds
    shorter than the mean solar day.



    --
    Steven
    Steven D'Aprano, Jul 5, 2012
    #2
    1. Advertising

  3. Chris Angelico

    Rick Johnson Guest

    On Jul 5, 10:19 am, Steven D'Aprano <steve
    > wrote:
    > The number of seconds in a day (true solar day) varies by between 13 and
    > 30 seconds depending on the time of the year and the position of the sun.


    Indeed. Which proves that a time keeping system based on the haphazard
    movements of celestial bodies is antiquated technology. Talk about job
    security!
    Rick Johnson, Jul 5, 2012
    #3
  4. On Fri, Jul 6, 2012 at 1:19 AM, Steven D'Aprano
    <> wrote:
    > On Thu, 05 Jul 2012 23:56:37 +1000, Chris Angelico wrote:
    >
    >> (The "magic number" 86400 is a well-known number, being seconds in a
    >> day.

    >
    > Does that include leap seconds?


    No it doesn't, hence...

    >> Feel free to replace it with 24*60*60 if it makes you feel better;
    >> I'm pretty sure Python will translate it into a constant at parse time.
    >> Or alternatively, have a module-level constant SECONDS_IN_A_DAY = 86400,
    >> in case that number should ever change.)

    >
    > "In case"?


    .... this not being entirely tongue-in-cheek. I believe the UTC spec
    allows for a progressive increase in the number of leap seconds, from
    the current "maybe one a year" at either Dec or June to having them
    multiple months a year, to having a leap second optionally every day,
    to having one a day and multiple leap seconds on some days. But it's
    not until we're actually in that last state (or close to it) that I
    would consider changing SECONDS_IN_A_DAY to 86401. Leap seconds are
    largely outside the concept of "dateless time".

    > The number of seconds in a day (true solar day) varies ...
    > it is also systematically slowing due to tidal friction.
    > ... in a mere thousand years, the length of the
    > mean solar day will be about a second longer.


    Yes. It's rather more likely to be an issue than, say, "PI = 3.14159"
    needing to change, but you do still have to consider what your
    definition of time is. If you're actually counting real
    time-since-epoch, then you need to either include leap seconds in your
    count (like TAI does) or ignore them (like Unix time does - divide
    Unix time by 86400 and you get the number of days since 1970, but a
    second's worth of Unix times "happen twice" when a positive leap
    second occurs). However, I think it would only surprise people if:

    23:30 + 03:45 = 03:14:59

    and they'd think it was an easter egg for displaying one of a geek's
    favorite numbers.

    > Imagine how much extra work we'll be able to get done!


    Oh, I reckon most people will waste it on sleep...

    ChrisA
    Chris Angelico, Jul 5, 2012
    #4
  5. On Fri, Jul 6, 2012 at 1:39 AM, Rick Johnson
    <> wrote:
    > On Jul 5, 10:19 am, Steven D'Aprano <steve
    > > wrote:
    >> The number of seconds in a day (true solar day) varies by between 13 and
    >> 30 seconds depending on the time of the year and the position of the sun.

    >
    > Indeed. Which proves that a time keeping system based on the haphazard
    > movements of celestial bodies is antiquated technology. Talk about job
    > security!


    The current *time keeping system* is based atomic clocks. It's only
    when you want to display this thing called "civil time" (so-called
    because it causes very uncivil arguments) that you concern yourself
    with astronomy, base 60, base 24, and other constructs.

    Now, if you want to argue about a poor choice of standard, look at
    so-called "Internet Time" that a Swiss watch company invented, which
    divides a day into 1000 beats. Why use the day as your basis and make
    it hard to convert to SI units reliably?

    ChrisA
    Chris Angelico, Jul 5, 2012
    #5
  6. On Fri, 6 Jul 2012 01:53:19 +1000, Chris Angelico <>
    declaimed the following in gmane.comp.python.general:

    > On Fri, Jul 6, 2012 at 1:19 AM, Steven D'Aprano
    > <> wrote:


    > > Imagine how much extra work we'll be able to get done!

    >
    > Oh, I reckon most people will waste it on sleep...
    >


    Well spend it forcing our computers to sync to the time servers
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
    Dennis Lee Bieber, Jul 6, 2012
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vlastimil Brom

    simpler increment of time values?

    Vlastimil Brom, Jul 5, 2012, in forum: Python
    Replies:
    5
    Views:
    218
    Steven D'Aprano
    Jul 6, 2012
  2. Chris Angelico

    Re: simpler increment of time values?

    Chris Angelico, Jul 5, 2012, in forum: Python
    Replies:
    0
    Views:
    154
    Chris Angelico
    Jul 5, 2012
  3. Mark Lawrence

    Re: simpler increment of time values?

    Mark Lawrence, Jul 5, 2012, in forum: Python
    Replies:
    0
    Views:
    157
    Mark Lawrence
    Jul 5, 2012
  4. Jason Friedman

    Re: simpler increment of time values?

    Jason Friedman, Jul 5, 2012, in forum: Python
    Replies:
    0
    Views:
    145
    Jason Friedman
    Jul 5, 2012
  5. Devin Jeanpierre

    Re: simpler increment of time values?

    Devin Jeanpierre, Jul 5, 2012, in forum: Python
    Replies:
    0
    Views:
    166
    Devin Jeanpierre
    Jul 5, 2012
Loading...

Share This Page