Repository navigation
How to handle more accurate date-time than seconds, for example milliseconds #289
Description
In practice times with an accuracy of seconds are not sufficient. You need more accuracy for example if you want to log at what time a message is received in a buffer.
Is it possible to standardize also the handling of more accurate time? Important then is to specify how to handle the comparison of times with different accuracies. For example, is 2026-01-23T19:00:00.20 equal to 2026-01-23T19:00:00.205?
Activity
TimvdLippe commentedon Jan 20, 2026
@BvanRaaij FYI
BvanRaaij commentedon Feb 4, 2026
I agree that not in all cases an accuracy of seconds is sufficient. Also ISO 8601 as wel as RFC9557 do support fractional seconds. My point with this rule is that:
Adding more precision than needed (especially using time components in date-only attributes) gives confusion and misinterpretation (due to time zone conversion)). Also always adding ".000" to every time component which practically does not have factional seconds is confusing and misleading (because it suggests an higher precision than real)
So: my suggestion would be to rewrite the rule allowing all formats in the intersection of ISO8606 and RFC 9557/3339 (which also includes fractional seconds)
mvdbro commentedon Feb 4, 2026
Your proposal is sensible.
However, don’t you never need more precision than milliseconds?
Unless everybody has to use the same precision for a certain time field, you have to specify rules for the comparison of times with different precision. In practice not everybody uses the same precision.
sergei-maertens commentedon Feb 4, 2026
Isn't this a matter of mathematical principles? You can only make comparisons with the lowest precision available and apply rounding rules accordingly. So in your example, yes, they are equal.
mvdbro commentedon Feb 5, 2026
It is indeed a matter of mathematical principles, but I think it’s good to state this principles explicitly.
You also have to pay attention to dates in which the day, the month or the year are not known, because such incomplete dates are used by the GBA. The LV WOZ, for example, doesnot follow mathematical principles for incomplete dates.
BvanRaaij commentedon Feb 5, 2026
Agree @mvdbro : this uncertainty topic is also discussen in issue 295
TimvdLippe commentedon Feb 5, 2026
Proposal: remove the example formats between parentheses in the ISO8601 column.
Since the name of the format is already given, we avoid the necessity to list all possible values. That way, if a particular value conforms to RFC9557 and ISO8601 it is considered legal. If there is uncertainty about values, then #295 indeed is the topic to discuss that.
What do you think?
BvanRaaij commentedon Feb 5, 2026
Agree to conform to the intersection of RFC9557 and ISO8601 but be aware that formats in this intersection this only apply to full dates, datetimes and times (with of without msecs) (because the RFC focusses only on them). So, this doesn't cover f.i periods, weeksnumbers and other data/time related data (which is fine for me now).
TimvdLippe commentedon Feb 5, 2026
Let's keep the list of requirements to only "date, datetime and time fields in requests and responses" as in the PR atm. I think that's already a massive way forward. Then in the future we can see if there is interest in standardizing on other field types as well. I updated the date-time PR to remove the examples, so as not to confuse anybody that we disallow anything special.
BvanRaaij commentedon Feb 5, 2026
Agree