Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
time: RFC3339Nano does not guarantee natural ordering #19635
When the time.Time used in Format(time.RFC3339Nano) is rounded to the nearest second (or anything lower than nanosecond), any trailing 0s are not formatted due to the formatting string.
I propose that time.RFC3339Nano is updated to the following formatting string:
or that a time.RFC3339NanoNatural (or similar) constant is declared
thanks for your time!
What version of Go are you using (
We can't change
We could introduce
I'm using my own constant defined right now, yes. Perhaps it's not worth the change, i just feel as though this should be raised or considered as we're declaring RFC3339 but not fully implementing it. My biggest issue with the new constant name is just that it doesn't look right
i also think it's worth noting that https://golang.org/doc/go1compat mentions that the team reserves the right to fix bugs, and i would consider this a bug
When using time as key in time-series databases such as BoltDB, the key is internally sorted by DB. This approach allows very fast search, however, a key has to be sortable.
If you come to accept this arguments, I also propose RFC3339MilliNatural, since it is sufficient in most real world cases (especially in IoT world) and on few million entries it saves a lot.
I understand that is is closed, and that you gave it a thought before, but I ask you to consider it maybe one more time.
You may argue that it's all just a simple matter of inserting format string, so one can simply introduce his own format const like
As for my proposal of adding Millis (natural), I have nothing but theoretical argument: most IoT devices work in sub 40MHz clock range. When they capture, process and at the end send event of interest to database backend (often using speeds like 9600bps), then using nano precision during logging is just wrong. If, on the other hand, device is capable to internally capture event related in time difference to previous one (like GPIO rising edge times), then Nano will be used anyway.
P.S. another problem one will encounter is that if you have variable number of digits of unpredictable length, then sending the same timestamp to different databases will result in different times being saved, due to the way trim or round is performed in different versions of same databases, and thus you cannot rely to query DB by exact date as noted here for MySQL
If you, however, do know the length of your time string, than it's easier to approach this problem.