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.
--
Peter Dalgaard, Professor
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: [email protected] Priv: [email protected]
______________________________________________
[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.
