Liam,
I think I have failed to convey my main point in the last e-mail - which was
that you want to parse the date/time in the timezone that you care about so in
your example that would be
> foo <- as.Date(33874, origin = "1899-12-30")
> foo
[1] "1992-09-27"
> as.POSIXlt(as.character(foo), "Europe/Berlin")
[1] "1992-09-27 CEST"
I was explicitly saying that you do NOT want to simply change the time zone on
POSIXlt objects as that won't work for reasons I explained - see my last e-mail.
Cheers,
Simon
> On 11/10/2022, at 6:31 AM, Liam Bailey <liam.bai...@liamdbailey.com> wrote:
>
> Hi all,
>
> Thanks Simon for the detailed response, that helps us understand a lot better
> what’s going on! However, with your response in mind, we still encounter some
> behaviour that we did not expect.
>
> I’ve included another minimum reproducible example below to expand on the
> situation. In this example, `foo` is a Date object that we generate from a
> numeric input. Following your advice, `bar` is then a POSIXlt object where we
> now explicitly define timezone using argument tz. However, even though we are
> explicit about the timezone the POSIXlt that is generated is always in UTC.
> This then leads to the issues outlined by Alexandre above, which we now
> understand are caused by DST.
>
> ``` r
> #Generate date from numeric
> #Not possible to specify tz at this point
> foo <- as.Date(33874, origin = "1899-12-30")
> dput(foo)
> #> structure(8305, class = "Date")
>
> #Convert to POSIXlt specifying UTC timezone
> bar <- as.POSIXlt(foo, tz = "UTC")
> dput(bar)
> #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
> #> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class = c("POSIXlt",
> #> "POSIXt"), tzone = "UTC")
>
> #Convert to POSIXlt specifying Europe/Berlin.
> #Time zone is still UTC
> bar <- as.POSIXlt(foo, tz = "Europe/Berlin")
> dput(bar)
> #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
> #> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class = c("POSIXlt",
> #> "POSIXt"), tzone = "UTC")
> ```
>
>
> We noticed that this occurs because the tz argument is not passed to
> `.Internal(Date2POSIXlt())` inside `as.POSIXlt.Date()`.
>
> Reading through the documentation for `as.POSIX*` we can see that this
> behaviour is described:
>
> > “Dates without times are treated as being at midnight UTC.”
>
> In this case, if we want to convert a Date object to POSIX* and specify a
> (non-UTC) timezone would the best strategy be to first coerce our Date object
> to character? Alternatively, `lubridate::as_datetime()` does seem to
> recognise the tz argument and convert a Date object to POSIX* with non-UTC
> time zone (see second example below). But it would be nice to know if there
> are subtle differences between these two approaches that we should be aware
> of.
>
> ``` r
> foo <- as.Date(33874, origin = "1899-12-30")
> dput(foo)
> #> structure(8305, class = "Date")
>
> #Convert to POSIXct specifying UTC timezone
> bar <- lubridate::as_datetime(foo, tz = "UTC")
> dput(as.POSIXlt(bar))
> #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
> #> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class = c("POSIXlt",
> #> "POSIXt"), tzone = "UTC")
>
> #Convert to POSIXct specifying Europe/Berlin
> bar <- lubridate::as_datetime(foo, tz = "Europe/Berlin")
> dput(as.POSIXlt(bar))
> #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
> #> year = 92L, wday = 0L, yday = 270L, isdst = 1L, zone = "CEST",
> #> gmtoff = 7200L), class = c("POSIXlt", "POSIXt"), tzone =
> c("Europe/Berlin",
> #> "CET", "CEST"))
> ```
>
> Thanks again for all your help.
> Alex & Liam
>
>> On 10 Oct 2022, at 6:40 pm, Hadley Wickham <h.wick...@gmail.com> wrote:
>>
>> On Sun, Oct 9, 2022 at 9:31 PM Jeff Newmiller <jdnew...@dcn.davis.ca.us>
>> wrote:
>>>
>>> ... which is why tidyverse functions and Python datetime handling irk me so
>>> much.
>>>
>>> Is tidyverse time handling intrinsically broken? They have a standard
>>> practice of reading time as UTC and then using force_tz to fix the
>>> "mistake". Same as Python.
>>
>> Can you point to any docs that lead you to this conclusion so we can
>> get them fixed? I strongly encourage people to parse date-times in the
>> correct time zone; this is why lubridate::ymd_hms() and friends have a
>> tz argument.
>>
>> Hadley
>>
>> --
>> http://hadley.nz
>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
