Time.local and offsets

Ruby
#1

Does anyone know why Time.local gives these offsets here? (+0100 is
correct)

[email protected]:~/rails/activerecord$ rvm use 1.8.7

info: Using ruby 1.8.7 p302
[email protected]:~/rails/activerecord$ ruby -e ‘p Time.local(2010); p
Time.local(1940); p Time.local(1807)’
Fri Jan 01 00:00:00 +0100 2010
Mon Jan 01 00:00:00 +0000 1940
Thu Jan 01 00:00:00 -0014 1807

[email protected]:~/rails/activerecord$ rvm use 1.9.2

info: Using ruby 1.9.2 p0
[email protected]:~/rails/activerecord$ ruby -e ‘p Time.local(2010); p
Time.local(1940); p Time.local(1807)’
2010-01-01 00:00:00 +0100
1940-01-01 00:00:00 +0000
1807-01-01 00:00:00 -0015

Local time zone is Europe/Madrid, the TZ environment variable is empty.

#2

Xavier N. wrote:

Does anyone know why Time.local gives these offsets here? (+0100 is
correct)

IIRC, daylight saving time was first introduced as a wartime
energy-saving measure. So prior to its introduction, Britain was on GMT
(+0000) even in the summer.

Wikipedia will almost certainly have the details.

#3

Sorry, I should engage brain before typing. Jan 1st is not in the
summer, and you are in Western Europe.

FWIW, I get similar results here for UK, under ruby 1.8.7.

irb(main):008:0> Time.local(1941)
=> Wed Jan 01 00:00:00 +0100 1941
irb(main):009:0> Time.local(1940)
=> Mon Jan 01 00:00:00 +0000 1940

#4

On Thu, Aug 26, 2010 at 3:55 PM, Brian C. [email protected]
wrote:

Sorry, I should engage brain before typing. Jan 1st is not in the
summer, and you are in Western Europe.

FWIW, I get similar results here for UK, under ruby 1.8.7.

irb(main):008:0> Time.local(1941)
=> Wed Jan 01 00:00:00 +0100 1941
irb(main):009:0> Time.local(1940)
=> Mon Jan 01 00:00:00 +0000 1940

It’s a bit weird (though I guess there’s an explanation).

This is a trace from Brian Lopez

[email protected] mysql2.git (master): ruby -e ‘p
Time.local(2010); p Time.local(1940); p Time.local(1807)’
Fri Jan 01 00:00:00 -0800 2010
Mon Jan 01 00:00:00 -0800 1940
Thu Jan 01 00:00:00 -0800 1807

This one is from José Valim

jose:~/Work[ree-1.8.7-2010.02][master]$ ruby -e ‘p Time.local(2010); p
Time.local(1940); p Time.local(1807)’
Fri Jan 01 00:00:00 -0200 2010
Mon Jan 01 00:00:00 -0300 1940
Thu Jan 01 00:00:00 -0306 1807

Have you noticed also that for 1807 I get -0014 and -0015?

#5

2010/8/26 Xavier N. [email protected]:

Does anyone know why Time.local gives these offsets here? (+0100 is correct)

% TZ=Europe/Madrid ruby -ve ‘p Time.local(2010); p Time.local(1940); p
Time.local(1807)’
ruby 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]
Fri Jan 01 00:00:00 +0100 2010
Mon Jan 01 00:00:00 +0000 1940
Thu Jan 01 00:00:00 -0014 1807
% TZ=Europe/Madrid ./ruby -ve ‘p Time.local(2010); p Time.local(1940);
p Time.local(1807)’
ruby 1.9.3dev (2010-08-26 trunk 29102) [x86_64-linux]
2010-01-01 00:00:00 +0100
1940-01-01 00:00:00 +0000
1807-01-01 00:00:00 -0014
% TZ=Europe/Madrid ./ruby -ve ‘p Time.local(2010); p Time.local(1940);
p Time.local(1807)’
ruby 1.9.2p0 (2010-08-18 revision 29034) [x86_64-linux]
2010-01-01 00:00:00 +0100
1940-01-01 00:00:00 +0000
1807-01-01 00:00:00 -0015
% zdump -v Europe/Madrid|head
Europe/Madrid -9223372036854775808 = NULL
Europe/Madrid -9223372036854689408 = NULL
Europe/Madrid Tue Jan 1 00:14:43 1901 UTC = Mon Dec 31 23:59:59 1900
LMT isdst=0 gmtoff=-884
Europe/Madrid Tue Jan 1 00:14:44 1901 UTC = Tue Jan 1 00:14:44 1901
WET isdst=0 gmtoff=0
Europe/Madrid Sat May 5 22:59:59 1917 UTC = Sat May 5 22:59:59 1917
WET isdst=0 gmtoff=0
Europe/Madrid Sat May 5 23:00:00 1917 UTC = Sun May 6 00:00:00 1917
WEST isdst=1 gmtoff=3600
Europe/Madrid Sat Oct 6 22:59:59 1917 UTC = Sat Oct 6 23:59:59 1917
WEST isdst=1 gmtoff=3600
Europe/Madrid Sat Oct 6 23:00:00 1917 UTC = Sat Oct 6 23:00:00 1917
WET isdst=0 gmtoff=0
Europe/Madrid Mon Apr 15 22:59:59 1918 UTC = Mon Apr 15 22:59:59 1918
WET isdst=0 gmtoff=0
Europe/Madrid Mon Apr 15 23:00:00 1918 UTC = Tue Apr 16 00:00:00 1918
WEST isdst=1 gmtoff=3600
% zdump -v Europe/Madrid|grep 2010
Europe/Madrid Sun Mar 28 00:59:59 2010 UTC = Sun Mar 28 01:59:59 2010
CET isdst=0 gmtoff=3600
Europe/Madrid Sun Mar 28 01:00:00 2010 UTC = Sun Mar 28 03:00:00 2010
CEST isdst=1 gmtoff=7200
Europe/Madrid Sun Oct 31 00:59:59 2010 UTC = Sun Oct 31 02:59:59 2010
CEST isdst=1 gmtoff=7200
Europe/Madrid Sun Oct 31 01:00:00 2010 UTC = Sun Oct 31 02:00:00 2010
CET isdst=0 gmtoff=3600

It seems Madrid used different timezone rules in these days:
LMT (local mean time) and WET/WEST.

Thu Jan 01 00:00:00 -0014 1807

14 is (884/60.0).floor.

1807-01-01 00:00:00 -0015

15 is (884/60.0).round.

#6

Brian C. wrote:

Time.parse(“1 jan 1847”)
=> Fri Jan 01 00:00:00 -0001 1847

Time.parse(“1 jan 1848”)
=> Sat Jan 01 00:00:00 +0000 1848

Time.local(“1847”).utc_offset
=> -75

Time.local(“1848”).utc_offset
=> 0

Sorry, I can’t explain that one. I’ve heard of half-hour time zones and
even quarter-hour ones, but not a minute and a quarter :slight_smile:

I think I have it:
http://en.wikipedia.org/wiki/Time_zone

It wasn’t until 1847 that Greenwich Mean Time was widely used across the
UK. Before then, everyone used “solar time”, which means that clocks at
different points of the country (east to west) hit noon at different
times. The difference would be 60 minutes for every 15 degrees of
longitude.

So if you were standing at St Paul’s Cathedral, say, noon would be
slightly later compared to noon in Greenwich, which is a bit to the
East.

In your case: Madrid has a longitude of 3 degrees 42 mins West. So the
offset of Madrid solar time from GMT is:

irb(main):001:0> -(3.0 + 42.0/60.0) / 15.0 * 60.0
=> -14.8

and that’s exactly what you saw. tzdata rules :slight_smile:

#7

On Fri, Aug 27, 2010 at 12:11 PM, Brian C. [email protected]
wrote:

Sorry, I can’t explain that one. I’ve heard of half-hour time zones and

and that’s exactly what you saw. tzdata rules :slight_smile:
Awesome!!!

Thank you very much :slight_smile:

#8

More info here:
http://www.nmm.ac.uk/explore/astronomy-and-time/time-facts/spring-forward-100-years-of-british-summer-time

In particular see “Permanent summer, 1968–71”, which is visible in Ruby:

require ‘time’
=> true

Time.parse(“1 jan 1968”)
=> Mon Jan 01 00:00:00 +0000 1968

Time.parse(“1 jan 1969”)
=> Wed Jan 01 00:00:00 +0100 1969

Time.parse(“1 jan 1970”)
=> Thu Jan 01 00:00:00 +0100 1970

Time.parse(“1 jan 1971”)
=> Fri Jan 01 00:00:00 +0100 1971

Time.parse(“1 jan 1972”)
=> Sat Jan 01 00:00:00 +0000 1972

So I’m pretty sure that the underlying tzinfo library is giving out true
information about what timezone was being used at the time.

This is a trace from Brian Lopez

[email protected] mysql2.git (master): ruby -e ‘p
Time.local(2010); p Time.local(1940); p Time.local(1807)’
Fri Jan 01 00:00:00 -0800 2010
Mon Jan 01 00:00:00 -0800 1940
Thu Jan 01 00:00:00 -0800 1807

Sure, well I guess that’s West Coast USA. The USA will have had its own
rules for this sort of thing.

This one is from José Valim

jose:~/Work[ree-1.8.7-2010.02][master]$ ruby -e ‘p Time.local(2010); p
Time.local(1940); p Time.local(1807)’
Fri Jan 01 00:00:00 -0200 2010
Mon Jan 01 00:00:00 -0300 1940
Thu Jan 01 00:00:00 -0306 1807

Argentina perhaps? Again, a different set of politics and rules.

Have you noticed also that for 1807 I get -0014 and -0015?

I get something similar:

Time.parse(“1 jan 1847”)
=> Fri Jan 01 00:00:00 -0001 1847

Time.parse(“1 jan 1848”)
=> Sat Jan 01 00:00:00 +0000 1848

Time.local(“1847”).utc_offset
=> -75

Time.local(“1848”).utc_offset
=> 0

Sorry, I can’t explain that one. I’ve heard of half-hour time zones and
even quarter-hour ones, but not a minute and a quarter :slight_smile:

B.

#9

On Thu, Aug 26, 2010 at 9:55 AM, Brian C. [email protected]
wrote:

Sorry, I should engage brain before typing. Jan 1st is not in the
summer, and you are in Western Europe.

Also, although daylight saving time WAS initiated as a war time
measure, the war was WW I, it was the Germans and their allies who
started it but Britain and other countries soon followed suit.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale