How to handle more accurate date-time than seconds, for example milliseconds

[mvdbro]

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?

[TimvdLippe]

@BvanRaaij FYI

[BvanRaaij]

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:

1. we should follow ISO 8601 and RFC9557 format standaards for date and time. See https://ijmacd.github.io/rfc3339-iso8601/ (which is based on RFC 3339 but for formatting ther is no difference with RFC 9557)
2. never add more precision than needed for your business case, so:

if you only need dates, use yyyy-mm-dd
if you need date+time (in seconds precision) use yyyy-mm-ddThh:mm:ssZ/±hh:mm
if you need date+time (in fractional seconds precision) use yyyy-mm-ddThh:mm:ss.sssZ/±hh:mm

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]

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]

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]

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]

Agree @mvdbro : this uncertainty topic is also discussen in issue 295

[TimvdLippe]

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]

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]

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]

Agree