You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
The text was updated successfully, but these errors were encountered: