[Rd] Possible POSIXlt / wday glitch & bugs.r-project.org status

Imanuel Costigan i.costigan at me.com
Sat Oct 5 05:18:22 CEST 2013


Ok thanks for that explanation. That's bad news for me. I need to generate dates out past that limit regularly. It means that many operations past that limit are unreliable. Any suggested work arounds / alternatives?

On 05/10/2013, at 11:37 AM, Joshua Ulrich <josh.m.ulrich at gmail.com> wrote:

> On Fri, Oct 4, 2013 at 8:02 PM, Imanuel Costigan <i.costigan at me.com> wrote:
>> Thanks for the responses and quoting the timezone help file.
>> 
>> I am assuming that in order to determine the wday element of POSIXlt, R does the necessary calculations in Julian time (via POSIXct). Based on this excerpt from ?DateTimeClasses, it looks like R is responsible for determining time zones post 2037 (the example I gave was in 2038). So it could be an R issue.
>> 
> It's an issue with size of the largest number you can store in a
> signed integer, which is not specific to R.
> 
>> .POSIXct(.Machine$integer.max, tz="UTC")
> [1] "2038-01-19 03:14:07 UTC"
> 
> Dates larger than that cannot be represented by a signed integer.  It
> could be worked around, but it's not trivial because R would have to
> use something other than the tm C struct.  Luckily, there's a decade
> or two before it starts to become a pressing issue. :)
> 
>>>     ‘"POSIXct"’ objects may also have an attribute ‘"tzone"’, a
>>>     character vector of length one.  If set to a non-empty value, it
>>>     will determine how the object is converted to class ‘"POSIXlt"’
>>>     and in particular how it is printed.  This is usually desirable,
>>>     but if you want to specify an object in a particular timezone but
>>>     to be printed in the current timezone you may want to remove the
>>>     ‘"tzone"’ attribute (e.g. by ‘c(x)’).
>>> 
>>>     Unfortunately, the conversion is complicated by the operation of
>>>     time zones and leap seconds (24 days have been 86401 seconds long
>>>     so far: the times of the extra seconds are in the object
>>>     ‘.leap.seconds’).  **The details of this are entrusted to the OS
>>>     services where possible.  This always covers the period 1970-2037,
>>>     and on most machines back to 1902 (when time zones were in their
>>>     infancy).  Outside the platform limits we use our own C code.
>> 
>> 
>> On 05/10/2013, at 12:59 AM, Scott Kostyshak <skostysh at princeton.edu> wrote:
>> 
>>> On Fri, Oct 4, 2013 at 6:11 AM, Imanuel Costigan <i.costigan at me.com> wrote:
>>>> Wanted to raise two questions:
>>>> 
>>>> 1. Is bugs.r-project.org down? I haven't been able to reach it for two or three days:
>>> 
>>> Yes. Quote from Duncan:
>>> 
>>>   ... the server is currently down. The volunteer who runs the server is
>>>   currently away from his office, so I expect it won't get fixed until he
>>>   gets back in a few days.
>>> 
>>> https://stat.ethz.ch/pipermail/r-help/2013-October/360958.html
>>> 
>>> Scott
>>> 
>>>> 
>>>> ```
>>>> ping bugs.r-project.org
>>>> PING rbugs.research.att.com (207.140.168.137): 56 data bytes
>>>> Request timeout for icmp_seq 0
>>>> Request timeout for icmp_seq 1
>>>> Request timeout for icmp_seq 2
>>>> Request timeout for icmp_seq 3
>>>> Request timeout for icmp_seq 4
>>>> Request timeout for icmp_seq 5
>>>> Request timeout for icmp_seq 6
>>>> ```
>>>> 
>>>> 2. Is wday element of POSIXlt meant to be timezone invariant? You would expect the wday element to be invariant to the timezone of a date. That is, the same date/time instant of 5th October 2013 in both Australia/Sydney and UTC should be a Saturday (i.e. wday = 6). And indeed that is the case with 1 min past midnight on 5 October 2013:
>>>> 
>>>> ```
>>>> library(lubridate)
>>>> d_utc <- ymd_hms(20131005000001, tz='UTC')
>>>> d_local <- ymd_hms(20131005000001, tz='Australia/Sydney')
>>>> as.POSIXlt(x=d_utc, tz=tz(d_utc))$wday # 6
>>>> as.POSIXlt(x=d_local, tz=tz(d_local))$wday # 6
>>>> ```
>>>> 
>>>> But this isn't always the case. For example,
>>>> 
>>>> ```
>>>> d_utc <- ymd_hms(20381002000001, tz='UTC')
>>>> d_local <- ymd_hms(20381002000001, tz='Australia/Sydney')
>>>> as.POSIXlt(x=d_utc, tz=tz(d_utc))$wday # 6
>>>> as.POSIXlt(x=d_local, tz=tz(d_local))$wday # 5
>>>> ```
>>>> 
>>>> Is this expected behaviour? I would have expected a properly encoded date/time of 2 Oct 2038 to be a Saturday irrespective of its time zone.
>>>> 
>>>> Obligatory system dump:
>>>> 
>>>> ```
>>>>> sessionInfo()
>>>> R version 3.0.1 (2013-05-16)
>>>> Platform: x86_64-apple-darwin12.4.0 (64-bit)
>>>> 
>>>> locale:
>>>> [1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8
>>>> 
>>>> attached base packages:
>>>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>>> 
>>>> other attached packages:
>>>> [1] lubridate_1.3.0 testthat_0.7.1  devtools_1.3
>>>> 
>>>> loaded via a namespace (and not attached):
>>>> [1] colorspace_1.2-4   dichromat_2.0-0    digest_0.6.3       evaluate_0.5.1
>>>> [5] ggplot2_0.9.3.1    grid_3.0.1         gtable_0.1.2       httr_0.2
>>>> [9] labeling_0.2       MASS_7.3-29        memoise_0.1        munsell_0.4.2
>>>> [13] parallel_3.0.1     plyr_1.8           proto_0.3-10       RColorBrewer_1.0-5
>>>> [17] RCurl_1.95-4.1     reshape2_1.2.2     scales_0.2.3       stringr_0.6.2
>>>> [21] tools_3.0.1        whisker_0.3-2
>>>> 
>>>> ```
>>>> 
>>>> Using R compiled by homebrew [1]. But also experiencing the same bug using R installed on Windows 7 from the CRAN binaries.
>>>> 
>>>> For those interested, I've also noted this on the `lubridate` Github issues page [2], even though this doesn't appear to be a lubridate issue.
>>>> 
>>>> Thanks for any help.
>>>> 
>>>> [1] http://brew.sh
>>>> [2] https://github.com/hadley/lubridate/issues/209
>>>> 
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>>> 
>>> --
>>> Scott Kostyshak
>>> Economics PhD Candidate
>>> Princeton University
>> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list