[R] R 3.1.0 interpreting large negative seconds since epoch as LMT?

[Prof Brian Ripley]

On 06/06/2014 10:03, peter dalgaard wrote:
>
> On 05 Jun 2014, at 15:43 , Pfuntner, John <John.Pfuntner at teradata.com> 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,                  ripley at stats.ox.ac.uk
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