[DRIVERS-937] Require that sub-millisecond precision times are rounded down to nearest millisecond when serializing Created: 02/Mar/20  Updated: 31/Mar/22

Status: Backlog
Project: Drivers
Component/s: BSON, Extended JSON
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Oleg Pudeyev (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to PYTHON-1603 datetime microseconds are rounded ins... Closed
related to RUBY-2145 bson 4.8.0 rounds Time during seriali... Closed

 Description   

Some languages like Ruby and Python support sub-millisecond precision for times. For example, Ruby supports nanosecond precision.

Neither bson nor extended json spec state how the additional precision is to be handled when conversion from language native time types is performed to bson or extended json. In Ruby and Python the initial implementation was to round the times which produced wrong results for people performing less than or equal queries as follows:

{'foo' => {'$lte' => <Time object>}}

Where Time object would round up, for example, to the next day if rounded to the nearest millisecond:

irb(main):002:0> a=Time.utc(2020, 1, 1, 0, 0, 0, 999_999)
irb(main):003:0> a
=> 2020-01-01 00:00:00.999999 UTC
irb(main):005:0> b=Time.at(a.to_f.round(3))
irb(main):006:0> b
=> 2019-12-31 19:00:01 -0500
irb(main):007:0> b.to_f
=> 1577836801.0

The solution adopted by both Ruby and Python is to truncate (floor) sub-millsecond component of the times when serializing to bson/extended json.

I propose the requirement to floor times to nearest millisecond when serializing is explicitly stated in the bson and extended json specifications.

It seems that JRuby got the flooring wrong for negative timestamps: https://github.com/jruby/jruby/issues/6104 In light of this I also suggest explicitly calling out negative timestamps, and that they also need to be rounded down.

cc shane.harvey


Generated at Thu Feb 08 08:22:37 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.