DavisVaughan
commented
3 years ago civil_date (or civil_year_month_day?) - A date class that has no implicit time zone. Different from Date because this has an implicit UTC time zone, which affects how it converts to POSIXct and back.
as.Date.civil_date would just convert to number of days since UTC epoch (sort of obvious). Retains ymd clock time
as.POSIXct.civil_date(x, tz = "UTC") would retain ymd clock time in local time zone, and would be at midnight. Possible for this to fail in some time zones because of DST - there are a few where midnight doesn't exist because it falls in a DST gap. In these cases it might be smart to give as.POSIXct.civil_date(x, tz = "UTC", nonexistant = , ambiguous = ) args with a decent default (in the nonexistant case, probably default to "next" closest value).
^ Should this default to UTC rather than local time zone? Would be different from as.POSIXct.Date, but would be consistent in a way because the absolute time would be the same. Better for reproducibility. Also has the default property where with_tz(as.POSIXct(x), "UTC") would return the same thing for Date and civil_date, which might be nice if warp auto converts to POSIXct this way.
as_civil_date.Date(x) would basically be a no-op if we kept the same internal data structure
as_civil_date.POSIXct(x) would use cctz to lookup ymd components, then would convert components to number of days since UTC epoch possibly using vroom's algo: https://github.com/r-lib/vroom/blob/be96e1e14b3855434c6b74925383144fd6c7d07d/src/DateTime.h#L121 or could expose this in warp as warp_years_ymonth_mday_to_days()
Could store like Date as number of days since UTC epoch, then use warp convert_days_to_components() whenever we need to make POSIXct/lt objects. For POSIXct, would also need cctz tooling to go from components to zoned time
These would all have no implicit time zone attached
year class for usage as a more explicit tsibble index