Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upCounter intuitive result when using anydate, is it a config problem I have ? #36
Comments
statquant
changed the title
|
That's a bug, and I can replicate it here when I use "TZ=Europe/London". Oddly, it does not happen for either my TZ or UTC. If you have a moment, can you chase it down? As you can see, the |
|
It behaves better when you use |
|
I will try to track it down this weekend. Thanks for answering |
|
Appreciate the help and second set of eyes. Some comtext: There is a (really long) issue thread #5 -- incidentally with the same problem right in the title -- happening for one locale in Australia (and I got a lot of testing help from @jason-turner2). This now makes it two. I am starting to suspect that it may be a Boost Date_time issue. I tried some variants around A simple test may just be to use I'll probably release 0.1.2 in the meantime as it fixes one other corner case bug. |
|
I am still not entirely sure where we loose that hour, but I think the best way about is to make |
|
Hello, I tried to create a pull request but could not do it. and I need to close RStudio, rebuild to get it working again (I cannot reproduce)... // given a ptime object, return (fractional) seconds since epoch
// account for localtime, and also account for dst
double ptToDouble(const bt::ptime & pt) {
const bt::ptime timet_start(boost::gregorian::date(1970,1,1));
bt::time_duration tdiff = pt - timet_start;
// hack-ish: go back to struct tm to use its tm_isdst field
time_t secsSinceEpoch = tdiff.total_seconds();
struct tm* localAsTm = localtime(&secsSinceEpoch);
//Rcpp::Rcout << "Adj is " << localAsTm->tm_isdst << std::endl;
// Define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG to use nanoseconds
// (and then use diff.total_nanoseconds()/1.0e9; instead)
//
// note dst correction here -- needed as UTC offset is correct but does not
// contain the additional DST adjustment
double totsec = tdiff.total_microseconds()/1.0e6, dstadj = 0;
#if defined(_WIN32)
if (totsec > 0) { // on Windows, for dates before 1970-01-01: segfault
dstadj = localAsTm->tm_isdst*60*60;
}
#else
dstadj = localAsTm->tm_isdst*60*60;
#endif
return totsec - dstadj;
}Stuff from Sys.setenv(TZ = "Australia/Sydney")
library(anytime)
anydate(20150101)
[1] "2015-01-01"Current issue anydate(20150101)
[1] "2015-01-01"
anydate('2016-12-12')
[1] "2016-12-12"
anytime('2016-12-12 15:00:00')
[1] "2016-12-12 15:00:00 GMT"
anytime('2016-05-12 15:00:00')
[1] "2016-05-12 15:00:00 BST" |
|
Let's take this one step at a time:
Updated:
|
|
That out of the way, you can still try to build in RStudio if you don't know how to build otherwise. Just try to run more tests on the command-line, maybe via RScript. Now: can you detail what you changed where? Did you commit something somewhere? |
|
Ok, I created a branch with the (shorter) version of R> as.POSIXct.numeric
function (x, tz = "", origin, ...)
{
if (missing(origin))
stop("'origin' must be supplied")
.POSIXct(as.POSIXct(origin, tz = "GMT", ...) + x, tz)
}
<bytecode: 0x5868e40>
<environment: namespace:base>
R> Here too the 'epoch timepoint' is computed with |
|
Rstudio: I usually not use it at all, that yet another reason, I had a Boost version mismatch bug on some unrelated project a week ago so I get it. What I changed: Only the 2 first lines of Did I commit: No I did not, I am not sure how to, I could clone, create a copy-repo and commit, but I thought the idiomatic way was to create a pull request. |
|
And the trouble is if I do what you suggest, it will only work in Greenwich, UK: That's just plain wrong by six hours. |
Super-annoying as hard to fix. In all these years with Rcpp and BH this is the first one from those projects. There must be a Date_Time object instantiation somewhere on each side.
Got that now, see above.
That is how you create a pull request. You clone (or fork), commit your change and the pull request is based the difference between your repo (or branch) and the repo you send the PR to, ie my master. Useful to learn that, and this repo is admirably small that you may as well learn. |
|
Ok, I feel this is along "Boost sets the local timezone on construction, R expects UTC as epoch, I want another timezone", please bear with me, I am on a blocked eurostar with limited wifi, I'll get back to it. |
|
What you suggest is something we may already have in the package. Did you ever look at |
|
I have it fixed now -- by converting to Date internally in the C++ code: Here the first one correctly returns Dec 18 in your case of a TZ for London. It uses the new (internal) argument For comparison |
|
This is now fixed in the master branch. |
|
Running the lattest anytime I still see the following behaviour: Do I misunderstand the expected behaviour ? |
|
Ah it looks like it is related to Europe/London TZ Goes back an Hour #51 |
|
@eddelbuettel Could you kindly confirm if the 2 examples I show 2 comments above are expected behavior, a yes/no will do. |
|
I think I have said all I am going to say in the matter. |
|
See #51 and the discussion there. Appears to be a bug with Boost. |
|
You could try and insert another line just before this line and create something like (untested, not compiled) (or maybe at a different spot where we have It's not a high priority item for me, but I would consider a careful pull request. |
|
I made such a pull request (or rather, a branch ready for a pull request). If you could test that, I would appreciate it. |
|
Before After However I would have expected the |
|
Interesting. I would encourage you to translate this into a pure C++ bug report and file it with Boost. (Also: you probably want a more uniform distribution of random dates, rather than a N(0, largeSd) around the epoch.) |
There is clearly a lot of error before 1901, and after 2038. But it is not clear that I can do anything about it. |
|
Plus 1940s which is weird. |
|
I played with this a little more -- when we use Boost to turn a numeric offset to the epoch into a string and parse that, we have fewer issues. The main problem here seems to be that we go to Boost, and then come back to R. Which seems to introduce some small frictions, |
I am trying to use anytime those days and I see results that seems counter intuitive to me.
I have the following:
Reading the vignette I understand that from
function (x, tz = getTZ(), asUTC = FALSE)thattzis NOT the timezone anytime uses to parse the data, which defaults to local (orUTCifasUTCisTRUE) but for "display". This makes sense as when you read data (from a string) you probably assume that the data is in your timezone.When I use
anydateI then getIs this the expected behaviour ?
I am not sure what I miss here.