More aggressively avoid S3 method extension

[DavisVaughan]

Use some of these check functions in the S3 generics:

check_date() # date_*()
check_weekday() # weekday_*()
check_duration() # duration_*()
check_calendar() # calendar_*()
check_naive_time() # naive_time_info()
check_sys_time() # sys_time_info()
check_time_point() # time_point_*()
check_zoned_time() # zoned_time_*()

clock isn't ready to be extensible yet. Not without some constructors and detailed docs about what makes up calendars / time points

[DavisVaughan]

Doesn't look possible because it would break datetimeoffset but we can probably use these checkers to improve some error messages anyways

[trevorld]

Doesn't look possible because it would break datetimeoffset but we can probably use these checkers to improve some error messages anyways

• Thanks for making sure not to break {datetimeoffset}!
• At your request {datetimeoffset} stopped extending calendar_*() methods and after you opened this issue {datetimeoffset} made sure not to extend any of the S3 generics you explicitly listed in this issue i.e. date_*(), weekday_*(), duration_*(), calendar_*(), naive_time_info(), sys_time_inf(), time_point_*(), and zoned_time_*()

• The CRAN version of {datetimeoffset} does extend S3 generics from {clock} (none of which were listed in this issue) with the following prefixes:

  • as_*()
  • get_*()
  • invalid_*()
  • set_*()

[DavisVaughan]

Ah ok I'll reconsider this then