[Rd] Possible POSIXlt / wday glitch & bugs.r-project.org status
Simon Urbanek
simon.urbanek at r-project.org
Sat Oct 5 20:18:27 CEST 2013
On Oct 5, 2013, at 4:51 PM, Sean O'Riordain <seanpor at acm.org> wrote:
> Some people (luckily not me anymore!) working with mortgages and
> pensions need to calculate up to 40 years into the future for the
> payment schedule.
>
Just to clarify since the Joshua's comment was ambiguous (and in part plain wrong) - R's POSIXct has no such limit since it doesn't use integers, so that is not really the issue here. As the original post suggested there may be a bug in handing some cases where conversions hit the system libraries (that may truncate to integers) and some cases may be worked around - and that remains to be investigated.
Cheers,
Simon
> On 5 October 2013 02:37, 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
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
More information about the R-devel
mailing list