Add "..." to "as_sys_time()"

[trevorld]

• Would it be okay to create a PR to add "..." to "as_sys_time()" to allow additional arguments?
• In particular I would like the option to add support for an ambiguous argument:

Currently

library("clock")
library("datetimeoffset") # remotes::install_github("trevorld/datetimeoffset")
dts <- c("2020-11-01T01:30:00[America/New_York]", # ambiguous sys time
         "2020-11-01T01:30:00-05:00",
         "2020-11-01T01:30:00-04:00")
dto <- as_datetimeoffset(dts)
as_sys_time(dto)

Error in `map()`:
ℹ In index: 1.
Caused by error in `stop_clock()`:
! Ambiguous time due to daylight saving time at location 1.
ℹ Resolve ambiguous time issues by specifying the `ambiguous` argument.

It could be nice to be able to support an ambiguous argument:

as_sys_time(dto, ambiguous = "NA")

<clock_sys_time[3]>
[1] NA "2020-11-01T06:30:00" "2020-11-01T05:30:00"

as_sys_time(dto, ambiguous = "earliest")

<clock_sys_time[3]>
[1] "2020-1101T05:30:00" "2020-11-01T06:30:00" "2020-11-01T05:30:00"

as_sys_time(dto, ambiguous = "latest")

<clock_sys_time[3]>
[1] "2020-1101T06:30:00" "2020-11-01T06:30:00" "2020-11-01T05:30:00"

Note since with pdf metadata datetimes we often don't know the time zone but more often know the UTC offsets the current strategy to convert to a zoned time is to first convert to a sys time and then convert to a zoned time. So converting to a zoned time (by first converting to a sys time) to then convert to a sys time would be awkward...

[trevorld]

In general the following {clock} coercion methods currently support ...:

• as_date_time()
• as_year_quarter_day()
• as_zoned_time()

The following {clock} coercion methods currently do not support ...:

• as_date()
• as_duration()
• as_iso_year_week_day()
• as_naive_time()
• as_sys_time()
• as_weekday()
• as_year_day()
• as_year_month_day()
• as_year_month_weekday()

[DavisVaughan]

Those 3 functions have ... for very specific reasons:

• as_zoned_time() because this is the only place in the low level API that has nonexistent and ambiguous arguments, and that design is purposeful. So the dots are there to separate the required and optional arguments.
• as_date_time() because that passes on to as_zoned_time(), so same reasons apply
• as_year_quarter_day() only because it requires an optional start argument to specify the quarter start

As mentioned elsewhere I do not currently see clock as an extensible system that you can convert in and out of from types that aren't natively supported at this time

[trevorld]

As mentioned elsewhere I do not currently see clock as an extensible system that you can convert in and out of from types that aren't natively supported at this time

I don't really understand why as a developer you'd want to deliberately make it harder for users/developers to get their date times into {clock}