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.
> ‘"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 <skost...@princeton.edu> wrote: > On Fri, Oct 4, 2013 at 6:11 AM, Imanuel Costigan <i.costi...@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@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- > Scott Kostyshak > Economics PhD Candidate > Princeton University ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
