-
Type: Spec Change
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Component/s: BSON, Extended JSON
-
None
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
- related to
-
PYTHON-1603 datetime microseconds are rounded instead of truncated
- Closed
-
RUBY-2145 bson 4.8.0 rounds Time during serialization to bson/extended json
- Closed