Davis Vaughan

You are correct that this is an _ambiguous time_. AFAIK, there is no way to return the other moment in time in lubridate. In clock, this is an error by...

Works with clock: ``` r clock::date_time_parse("999-1-1 00:00:00", "UTC") #> [1] "0999-01-01 UTC" ``` Created on 2021-05-25 by the [reprex package](https://reprex.tidyverse.org) (v1.0.0)

I just hit this too with ` - hours(1)`. It was pretty unfortunate, it wrecked a pretty long series spanning multiple years. Crossing over the DST boundary is definitely what...

Okay, so I think that there is a bug that has been there since essentially the beginning of the package. The summary is that I think that right here, there...

Hmm okay I think the rule could be if we land in the spring forward daylight savings time gap and `(period size) [1] "2011-03-13 01:00:00 EST" one_hour_one_second_before_border [1] "2011-03-13 00:59:59...

For anyone doing arithmetic with _hours, minutes, or seconds_ with lubridate, you likely want to use Durations objects (like `dhours()`) rather than Period objects (like `hours()`). For arithmetic with more...

> However: dminutes should not act different from minutes. This is confusing at best. I disagree. The whole reason there are two functions for adding minutes is that they work...

> Here's how I'd expect hours and dhours to act: Hmm, @pitakakariki from this example it looks to me like you might misunderstand how Period and Duration are supposed to...

As Vitalie mentioned here https://github.com/tidyverse/lubridate/issues/759#issuecomment-536286765, the reversibility rule is probably not the best idea for date time arithmetic, even if it sounds like a good idea (I agree with him...

clock takes the same approach as readr by providing OS independent locale specification when formatting and parsing: ``` r library(clock) x [1] "01-juillet-2020" ``` Created on 2021-05-25 by the [reprex...