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

[peter dalgaard]

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.

-- 
Peter Dalgaard, Professor
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com