Open theduke opened 1 year ago
Creating a new datatype or not is a tough decision. I tend to gravitate to keep the amount of datatypes to a minumum. If a datatype can actually be represented as a Property, things are often far easier.
Basically, as a rule of thumb, I currently always ask the question: does this new datatype require a new type of input for forms? And if it does, is the datatype reusable in multiple semantic relationships?
For Duration, I think there are definitely scenarios were I'd expect a new type of form. For example if I'm planning a holiday on AirBnB I want a date-range select. And in a calendar appointment, too. But these make more sense to represent as two seperate fields: start-date and end-date.
Which usecases did you have in mind? Can you come up with multiple Properties that would use this datatype?
I tend to gravitate to keep the amount of datatypes to a minumum
I concur, but duration is a common type which has a distinct semantic meaning not subsumed by a timestamp or a plain integer.
Example use cases:
I think it's common enough and distinct enough to have a dedicated core datatype.
Define a datatype for specifying a duration.
The main question is if millisecond precision is enough, or if sub-millisecond precision is required often enough.
I lean towards just specifying it as milliseconds.