Is it Time bug?

Hi all! I’m writing program some days ago which calculates every
Thursday day in interval given by 2 Time values and see interesting
result described later. Is it my or ruby bug?

Result

Thu Sep 01 00:00:00 MSD 2005
Thu Sep 08 00:00:00 MSD 2005
Thu Sep 15 00:00:00 MSD 2005
Thu Sep 22 00:00:00 MSD 2005
Thu Sep 29 00:00:00 MSD 2005
Thu Oct 06 00:00:00 MSD 2005
Thu Oct 13 00:00:00 MSD 2005
Thu Oct 20 00:00:00 MSD 2005
Thu Oct 27 00:00:00 MSD 2005
Wed Nov 02 23:00:00 MSK 2005
Wed Nov 09 23:00:00 MSK 2005
Wed Nov 16 23:00:00 MSK 2005
Wed Nov 23 23:00:00 MSK 2005
Wed Nov 30 23:00:00 MSK 2005
Wed Dec 07 23:00:00 MSK 2005

Code

t1 = Time.mktime(2005, 9, 1)
t2 = Time.mktime(2005, 12, 11)
while t1.to_i < t2.to_i
p t1
t1 += 3600247
end

Valerij KIR wrote:

Thu Sep 22 00:00:00 MSD 2005
Wed Dec 07 23:00:00 MSK 2005

This is what I get. Looks like it is the effect of the PDT->PST time
change (or in your case MSD->MSK).

Thu Sep 01 00:00:00 Pacific Daylight Time 2005
Thu Sep 08 00:00:00 Pacific Daylight Time 2005
Thu Sep 15 00:00:00 Pacific Daylight Time 2005
Thu Sep 22 00:00:00 Pacific Daylight Time 2005
Thu Sep 29 00:00:00 Pacific Daylight Time 2005
Thu Oct 06 00:00:00 Pacific Daylight Time 2005
Thu Oct 13 00:00:00 Pacific Daylight Time 2005
Thu Oct 20 00:00:00 Pacific Daylight Time 2005
Thu Oct 27 00:00:00 Pacific Daylight Time 2005
Wed Nov 02 23:00:00 Pacific Standard Time 2005
Wed Nov 09 23:00:00 Pacific Standard Time 2005
Wed Nov 16 23:00:00 Pacific Standard Time 2005
Wed Nov 23 23:00:00 Pacific Standard Time 2005
Wed Nov 30 23:00:00 Pacific Standard Time 2005
Wed Dec 07 23:00:00 Pacific Standard Time 2005

First of all for doing stuff like this I highly recommend checking out
Runt [1], it’s a temporal expression library. Think regular
expressions for time.

Anyway I think it has to do with the fact that that the Date lib
accounts for leap years, but your code doesn’t. To explain it a bit…

There are 365.25 days in a year, not 365. This means that there are
31557600 seconds in a year, rather than the 31536000 that your code
would generate. That leaves you with 21600 unnoticed seconds. 365 /
21600 = 0.0168981481, which is how many seconds are lost in each day.
There are 63 days between your start date of Sep 01 and the “weird”
date of Nov 02. 63 * 0.0168981481 = 1.03, so there’s one lost second,
causing the day to not roll over.

Pretty fun, huh? :slight_smile:

Now that I’ve taken the time to identify the problem, I honestly don’t
feel like solving it…but hopefully you can get started with this new
found info :slight_smile: Again, I’d recommend checking out runt.

Pat

[1] http://runt.rubyforge.org/

On 1/29/06, Joel VanderWerf [email protected] wrote:

Thu Sep 15 00:00:00 MSD 2005
Wed Nov 30 23:00:00 MSK 2005
end
Thu Oct 06 00:00:00 Pacific Daylight Time 2005

vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Damn, you win. Thought I had found an interesting “gotcha” :slight_smile:

Pat M. [email protected] writes:

21600 = 0.0168981481, which is how many seconds are lost in each day.
There are 63 days between your start date of Sep 01 and the “weird”
date of Nov 02. 63 * 0.0168981481 = 1.03, so there’s one lost second,
causing the day to not roll over.

Pretty fun, huh? :slight_smile:

I don’t believe that this is the cause of the problem here. Changing
the dates from 5/1/2005 to 7/11/2005 (just shifting everything back 4
months) does not cause the same effect. This is a daylight savings time
issue, not a seconds-per-year issue. In 2005, daylight savings time
went into effect on April 3, 2005, and terminated on 30 October, 2005
… at least in the USA.

t1 = Time.mktime(2005, 5, 1)
t2 = Time.mktime(2005, 7, 11)
while t1.to_i < t2.to_i
p t1
t1 += 3600247
end

Sun May 01 00:00:00 EDT 2005
Sun May 08 00:00:00 EDT 2005
Sun May 15 00:00:00 EDT 2005
Sun May 22 00:00:00 EDT 2005
Sun May 29 00:00:00 EDT 2005
Sun Jun 05 00:00:00 EDT 2005
Sun Jun 12 00:00:00 EDT 2005
Sun Jun 19 00:00:00 EDT 2005
Sun Jun 26 00:00:00 EDT 2005
Sun Jul 03 00:00:00 EDT 2005
Sun Jul 10 00:00:00 EDT 2005

Every day has exactly 86400 seconds (except every few years when a
leap-second is added/subtracted). The seconds-per-year issue is covered
by leap years.

On 1/30/06, Lloyd Z. [email protected] wrote:

31557600 seconds in a year, rather than the 31536000 that your code
months) does not cause the same effect. This is a daylight savings time
issue, not a seconds-per-year issue.

Yeah, I realized that. To quote my reply to Joel, who uncovered the
real issue:
“Damn, you win. Thought I had found an interesting ‘gotcha’ :)”

Lloyd Z. [email protected] writes:

31557600 seconds in a year, rather than the 31536000 that your code
Every day has exactly 86400 seconds (except every few years when a
leap-second is added/subtracted). The seconds-per-year issue is covered
by leap years.

… except on the daylight savings time transitions, of course. In that
year in the USA, April 3 had 82,800 seconds, and October 30 had 90,000
seconds, which accounts for the discrepancy in the original date range.

Also, the seconds-lost-per-day calculation above isn’t correct. You
need to divide 21600 by 365, not the other way around. This yields a
bit less than one minute per day.