[R] puzzled by time zone quirk

[Prof Brian Ripley]

You neglected to update before posting as required by the posting guide.

R 3.0.2 is far from current, and on OS X the timezone internals were 
replaced in R 3.1.x (the previous version did not handle 64-bit time_t 
correctly, even though that is what OS X uses).  And the documentation 
is different.


On 21/09/2014 15:39, Denis Chabot wrote:
> Sorry, I had not posted in a long time and I remembered this as I pushed the "send" button.
>
> And I am not surprised that I thought wrong!
>
> I'll start with the missing information:
>
>> sessionInfo()
> R version 3.0.2 (2013-09-25)
> Platform: x86_64-apple-darwin10.8.0 (64-bit)
>
> locale:
> [1] fr_CA.UTF-8/fr_CA.UTF-8/fr_CA.UTF-8/C/fr_CA.UTF-8/fr_CA.UTF-8
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] tools_3.0.2
>
> Then I'll admit that some of the very useful details you provided had escaped me, but in my defense, I took to heart one element found in ?Sys.timezone:
>
> It is not in general possible to retrieve the system's own name(s) for the current timezone, but Sys.timezone will retrieve the name it uses for the current time (and the name may differ depending on whether daylight saving time is in effect).
>
> When I tell my computer that I am in Europe, I get
> Sys.time()
> [1] "2014-09-21 16:38:45 CEST"
>
> As the output of my "c" also displayed "CEST", I assumed this was the preferred way to refer to that time zone. Because of this, I had expected c and d to be the same. The output of c is deceiving. But at least I now know not to use "CEST".
>
> Denis
>
> Le 2014-09-21 à 10:00, Prof Brian Ripley <ripley at stats.ox.ac.uk> a écrit :
>
>> On 21/09/2014 14:11, Denis Chabot wrote:
>>> Hi,
>>>
>>> I have to deal with time-stamped data coming from outside my own time zone, so the problem is likely poor knowledge of European time zones on my part. But I am puzzled just the same.
>>>
>>> I thought that setting a time zone of "Europe/Copenhagen" would be the same as "CET" in winter and "CEST" in summer.
>>
>> You thought wrong: CEST is not a valid timezone on most (maybe all) R platforms.
>>
>> You failed to tell us the 'at a minimum' information required by the posting guide.  ?Sys.timezone says OlsonNames() tells you the timezone names supported on your unstated platform, and  ?as.POSIXct says
>>
>>       tz: A time zone specification to be used for the conversion, _if
>>           one is required_.  System-specific (see time zones), but ‘""’
>>           is the current time zone, and ‘"GMT"’ is UTC (Universal Time,
>>           Coordinated). Invalid values are most commonly treated as
>>           UTC, on some platforms with a warning.
>>
>>
>> As the posting guide asks, please do your own homework.
>>
>>
>>> This test in winter works as expected:
>>>
>>>> a = as.POSIXct("2013-02-25 01:00:00", tz="Europe/Copenhagen"); a
>>> [1] "2013-02-25 01:00:00 CET"
>>>> b = as.POSIXct("2013-02-25 01:00:00", tz="CET"); b
>>> [1] "2013-02-25 01:00:00 CET"
>>>> a-b
>>> Time difference of 0 secs
>>>
>>> But this one is summer does not work as I expected:
>>>
>>>> c = as.POSIXct("2013-07-25 01:00:00", tz="Europe/Copenhagen"); c
>>> [1] "2013-07-25 01:00:00 CEST"
>>>> d = as.POSIXct("2013-07-25 01:00:00", tz="CEST"); d
>>> [1] "2013-07-25 01:00:00 UTC"
>>>> e = as.POSIXct("2013-07-25 01:00:00", tz="CET"); e
>>> [1] "2013-07-25 01:00:00 CEST"
>>>> c-d
>>> Time difference of -2 hours
>>>> c-e
>>> Time difference of 0 secs
>>>
>>> Setting tz to "Europe/Copenhagen" in summer in c first appears to be the same as setting it to "CEST" because the output is showing "CEST".
>>>
>>> But d should then be the same as c, and it is not.
>>>
>>> What is happening?
>>>
>>> Thanks in advance,
>>>
>>> Denis Chabot
>>>
>>> ______________________________________________
>>> R-help at r-project.org 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.
>>>
>>
>>
>> --
>> Brian D. Ripley,                  ripley at stats.ox.ac.uk
>> Emeritus Professor of Applied Statistics, University of Oxford
>> 1 South Parks Road, Oxford OX1 3TG, UK
>>
>> ______________________________________________
>> R-help at r-project.org 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.
>


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK