Clarify duration values as integers#10356
Conversation
There was a problem hiding this comment.
Currently it seems decimal values actually work. I suggest that we update the docs like this (only suggesting usage of integers), and then as a follow up also change the code so that only integer values are supported.
This is necessary to avoid confusion such as what is 0.5 months? Or even others like 1.30m ... is that one minute and 30 seconds .. so really 1.5m ? E.g. in this case users should just use 90s.
Wdyt @electrum ? Also .. this might have to be done in Airlift..
hashhar
left a comment
There was a problem hiding this comment.
The existing docs are correct.
Changing allowed values is not feasible due to multiple reasons IMO:
- It's a breaking change without a good-enough justification.
- It might not be straightforward to limit to only integer values since a Duration object can constructed in many ways - only one of which is via human readable string.
I'll defer to @electrum for a decision on this.
Duration only supports units up to days, for that specific reason. So there's no confusion there.
Not sure what's ambiguous about that. It's 1.3 minutes (just a fractional number), not 1:30 minutes.
What's wrong with using 1.5 minutes? The natural magnitude of a setting (what you intuitively think about) might be in terms of minutes, or hours, or days. For instance, what if you want to represent "a tenth of a day"? If you can't use fractional numbers, you can't say "0.1d", or even the equivalent in hours (i.e., "2.4h"). You'd need to say "144m", which is hard to mentally relate to the length of a day.
No, that was an intentional design choice in Airlift, and it needs to be that way for may other reasons. |
|
Closing this PR, will follow up shortly with another PR that clarifies how decimal duration values are handled. |
Clarify that
durationtype values must be integers.