The presence of .days() etc was brought up in the original Clock pitch and was deliberately removed from the pitch. It could certainly be re-added (and there are some decent ideas suggested in this thread), but it would need to address the concerns brought up in the original thread around their inclusion. For example:
-
The name
.days()is bad. A "day" is technically a duration, but it's a duration that is derived from the calendar against which a "day" is being measured, and Foundation supports many different kinds of calendars. Therefore,.days(1)can represent different absolute durations depending on which calendar you choose to use. (As a dumb example, days on Mars are longer than days on Earth) -
Even when using a same calendar, a "day" is still a variable-length duration. Sometimes days are 23 hours, usually they're 24, and sometimes they're 25. Depending on what you're defining a "day" as, a "day" can technically be as long as 50 hours.
-
"Weeks" are conventionally 7 days long, but there have been historical variations, and there's no guarantee future calendars will also use 7 day weeks.
Can we work around these issues by picking new names? Sure, we could probably use .siDays() and .siWeeks() to mean durations of 86,400 SI seconds and 604,800 SI seconds respectively, but remember that these are all different kinds of clocks. Does it make sense to advance a ContinuousClock by 3 SI days? Is that the same expected duration as advancing a SuspendingClock? What if I define a custom Clock that performs Calendar-based operations; should .siDays(1) still mean 86,400 seconds, or should it mean "one calendrical day of variable length"?
We quickly run in to issues around expectations when we introduce calendrical concepts onto a type that does not natively support calendars. Recall that the original pitch around Clock deliberately avoided calendars as part of the base proposal, but instead left that up to be determined by the conforming type.