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 upWrong calculation of Isoweek for year 2015 (in tz != "UTC") #2407
Comments
|
Following up on my SO comment -- without a reproducible example, I can't confirm this works, but it seems the answer is to change: https://github.com/Rdatatable/data.table/blob/master/R/IDateTime.R#L275
To
(that's what is seems is done by
(actually, on further look, these look the same. leaving this for my own notes) |
|
data.table::isoweek("2014-12-29")
|
|
@SimonCoulombe thanks! I've spotted the problem and will push a fix soon. |
As posted in https://stackoverflow.com/questions/43944430/r-why-does-the-default-package-for-isoweek-change-depending-how-i-use-it/46655291#46655291 data.table isoweek function sometimes gives a different result of ISO standart.
I found an explination, running data.table function step by stepThe first step of function is converting Date as.POSIXlt.
The result will be different if you input a character or a Date
as.POSIXlt('2015-01-02')[1] "2015-01-02 COT"as.POSIXlt(as.Date('2015-01-02'))[1] "2015-01-02 UTC"As you can see, what change is the time Zone.
In the third step of function, in both cases, it returns a Date in Local time
(year_start <- as.POSIXct(paste0(as.POSIXlt(nearest_thurs)$year +1900L, "-01-01")))[1] "2015-01-01 COT"That way, in the forth and last step, the date difference between UTC and Local time gives some decimals 'aditional' to time difference between Local Time dates (in my case 5 hours, or 0.208). That is why the final result of weeks changes.
In conclusion, if you force date as character, the function will calculate everything in Local time and the result will be right
-- | --