On 06/06/2014 10:03, peter dalgaard wrote:
On 05 Jun 2014, at 15:43 , Pfuntner, John <[email protected]> wrote:
I'm seeing a weird difference in behavior between R versions 3.0.2 and 3.1.0.
Consider this session from version 3.0.2:
secs = c(-6327530133, -632753013, -63275301, -6327530, -632753, -63275, -6327,
-632, -63)
class(secs) = c('POSIXt', 'POSIXct')
secs
[1] "1769-06-27 11:44:27 EST" "1949-12-13 06:16:27 EST" "1967-12-30 10:31:39 EST"
"1969-10-19 14:21:10 EDT"
[5] "1969-12-24 11:14:07 EST" "1969-12-31 01:25:25 EST" "1969-12-31 17:14:33 EST"
"1969-12-31 18:49:28 EST"
[9] "1969-12-31 18:58:57 EST"
This looks pretty good but if I run the exact same statements on version 3.1.0,
I get a different timezone for the first time:
secs = c(-6327530133, -632753013, -63275301, -6327530, -632753, -63275, -6327,
-632, -63)
class(secs) = c('POSIXt', 'POSIXct')
secs
[1] "1769-06-27 11:48:25 LMT" "1949-12-13 06:16:27 EST" "1967-12-30 10:31:39 EST"
"1969-10-19 14:21:10 EDT"
[5] "1969-12-24 11:14:07 EST" "1969-12-31 01:25:25 EST" "1969-12-31 17:14:33 EST"
"1969-12-31 18:49:28 EST"
[9] "1969-12-31 18:58:57 EST"
I've never even heard of LMT before!! I found a page on Wikipedia
(http://en.wikipedia.org/wiki/Local_mean_time) that talks about "local mean
time" which was used in the 19th century before standard times were adopted.
Is this a bug or a deliberate change in R 3.1.0?
It's not likely a bug, nor a particularly deliberate change to R, but NEWS.Rd
reads:
\item Platforms with a 64-bit \code{time_t} type are allowed to
handle conversions between the \code{"POSIXct"} and
\code{"POSIXlt"} classes for date-times outside the 32-bit range
(before 1902 or after 2037): the existing workarounds are used on
other platforms. (Note that time-zone information for post-2037
is speculative at best, and the OS services are tested for known
errors and so not used on OS X.)
Currently \code{time_t} is usually \code{long} and hence 64-bit on
Unix-alike 64-bit platforms: however it several cases the
time-zone database is 32-bit. On \R for Windows it is 64-bit (for
both architectures as from this version).
so presumably, your (unstated) OS has particular ideas of what the times were
like in 1769, and those ideas have kicked in starting with R-3.1.0.
The 4:02 minute shift is curious though. It's close to a meridian shift of 1
degree of arc (1° is 24h/360 = 4 minutes).
On OSX Mavericks, in Copenhagen, I get a shift in the opposite direction of almost 10 minutes, from
"1769-06-27 17:44:27 CET" to "1769-06-27 17:34:47 LMT". One might speculate
that this comes from the Copenhagen Meridian at 12° 34Ⲡ32.25ⳠE being about 2.5 degrees of
arc short of GMT+1 (at 15° 0´ E). If you're at about 74W (e.g., New York time), it sort of all
figures.
As almost all platforms are using the IANA (formerly Olson) database,
this is the most likely explanation. That has
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Europe/Copenhagen 0:50:20 - LMT 1890
0:50:20 - CMT 1894 Jan 1 # Copenhagen MT
1:00 Denmark CE%sT 1942 Nov 2 2:00s
1:00 C-Eur CE%sT 1945 Apr 2 2:00
1:00 Denmark CE%sT 1980
1:00 EU CE%sT
# US eastern time, represented by New York
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/New_York -4:56:02 - LMT 1883 Nov 18 12:03:58
-5:00 US E%sT 1920
-5:00 NYC E%sT 1942
-5:00 US E%sT 1946
-5:00 NYC E%sT 1967
-5:00 US E%sT
so that says New York switched to EST in 1883 by 3:58 (not 4:02).
--
Brian D. Ripley, [email protected]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
