Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #24913 > unrolled thread

Re: simpler increment of time values?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: simpler increment of time values? Chris Angelico <rosuav@gmail.com> - 2012-07-05 23:56 +1000
    Re: simpler increment of time values? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-05 15:19 +0000
      Re: simpler increment of time values? Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-05 08:39 -0700
        Re: simpler increment of time values? Chris Angelico <rosuav@gmail.com> - 2012-07-06 01:59 +1000
      Re: simpler increment of time values? Chris Angelico <rosuav@gmail.com> - 2012-07-06 01:53 +1000
      Re: simpler increment of time values? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-06 00:42 -0400

#24913 — Re: simpler increment of time values?

On Thu, Jul 5, 2012 at 11:18 PM, Vlastimil Brom
<vlastimil.brom@gmail.com> 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

[toc] | [next] | [standalone]

#24926

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

[toc] | [prev] | [next] | [standalone]

#24930

On Jul 5, 10:19 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> 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!

[toc] | [prev] | [next] | [standalone]

#24932

On Fri, Jul 6, 2012 at 1:39 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Jul 5, 10:19 am, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#24931

On Fri, Jul 6, 2012 at 1:19 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#24954

On Fri, 6 Jul 2012 01:53:19 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:

> On Fri, Jul 6, 2012 at 1:19 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> 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
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web