Forum: open-discussion
Monitor Forum | 
Start New Thread
| RE: Bug in as.yearqtr? [ Reply ] By: Joshua Ulrich on 2020-12-17 15:23 | [forum:48569] |
| Thanks for pointing that out Ken! FWIW, I noticed the same thing and accounted for that in my analysis and response. But I forgot to mention it. | |
| RE: Bug in as.yearqtr? [ Reply ] By: Achim Zeileis on 2020-12-17 00:10 | [forum:48565] |
| Good catch, Ken! I guess it was not intentional. And I didn't notice because I'm in the same timezone as Europe/Berlin... | |
| RE: Bug in as.yearqtr? [ Reply ] By: Ken Williams on 2020-12-16 23:29 | [forum:48564] |
| Was it intentional to use `TZ` instead of `tz` in your example? The correct argument is `tz`, so those variables are (silently) constructed with no timezone passed, and thus get "the current time zone", which is somewhat unpredictable. | |
| RE: Bug in as.yearqtr? [ Reply ] By: Achim Zeileis on 2020-12-16 16:55 | [forum:48563] |
| Thanks Josh very helpful! That all sounds very plausible to me... | |
| RE: Bug in as.yearqtr? [ Reply ] By: Joshua Ulrich on 2020-12-16 16:31 | [forum:48562] |
|
This behavior in as.yearmon.POSIXt() has been in place since 2005, so I'm not sure how likely it is we will change it. In 2010, the documentation for ?as.yearmon was updated with: "In the case of 'as.yearmon.POSIXt' the conversion is with respect to GMT. (Use 'as.yearmon(format(...))' for other time zones.)" That said, I can see how this is surprising. as.POSIXlt.POSIXct() checks for missing tz, NULL tz, and non-NULL tzone attribute. As you noted, leaving tz missing causes as.POSIXlt.POSIXct() to use the tzone attribute which results in a correct conversion. I also see that as.POSIXlt() was converted to a generic in base R in 2007-09 (r42996). That change may have fixed the issue that setting tz="GMT" was meant to work-around. Some testing would be needed to confirm my hypothesis. |
|
| RE: Bug in as.yearqtr? [ Reply ] By: Achim Zeileis on 2020-12-16 16:19 | [forum:48561] |
|
Christopher, thanks for pointing this out. This matches the difference in behavior from base R when going via as.Date(): R> as.Date(d.date.POSIXct) [1] "2018-12-31" R> as.Date(d.date.POSIXlt) [1] "2019-01-01" IIRC this was the reason for this behavior. I'll also ping Gabor to see what he thinks. |
|
| Bug in as.yearqtr? [ Reply ] By: Christopher Kurschat on 2020-12-16 11:29 | [forum:48560] |
|
Hello, I am not sure if it's a bug or feature. I get following behavior using the function as.yearqtr d.date.POSIXlt <- as.POSIXlt("2019-01-01 00:00:00", TZ= "Europe/Berlin") d.date.POSIXct <- as.POSIXct("2019-01-01 00:00:00", TZ= "Europe/Berlin") as.yearqtr(d.date.POSIXlt) # output 2019 Q1 as.yearqtr(d.date.POSIXct) # output 2018 Q4 I tracked it down to: as.yearmon(d.date.POSIXlt) # output Jan 2019 as.yearmon(d.date.POSIXct) # output Dez 2018 At this moment I am not sure which function is called next, but I guess its: as.yearmon.POSIXt <- function(x, ...) as.yearmon(with(as.POSIXlt(x, tz="GMT"), 1900 + year + mon/12)) as.yearmon(with(as.POSIXlt(d.date.POSIXlt, tz="GMT"), 1900 + year + mon/12)) # output Jan 2019 as.yearmon(with(as.POSIXlt(d.date.POSIXct, tz="GMT"), 1900 + year + mon/12)) # output Jan Dez 2018 If I omit tz="GMT" I get for both dates the correct YearMonth: as.yearmon(with(as.POSIXlt(d.date.POSIXlt), 1900 + year + mon/12)) as.yearmon(with(as.POSIXlt(d.date.POSIXct), 1900 + year + mon/12)) kind regards Christopher |
|
