This feature was suggested by @ssanderson at:
Currently, we have TimeRFC3339Nano option for encoding to CBOR time (tag 0) with nanosecond precision. However, it retains the timezone of time.Time being encoded and it can be inconvenient to set time.Time to UTC before encoding it to CBOR.
NOTE: The TimeUnix option (default setting) uses 1-second precision, UTC, and encodes to integer (CBOR tag 1). It is the recommended setting unless you need fractional seconds.
If user apps need to encode UTC time with nanosecond precision to integer (instead of string), then that is supported by this library in the API for user-defined CBOR tags.
RFC 8949 and Time
RFC 8949 defines CBOR tag 0 and tag 1 for encoding time using integer, floating point, or string value.
Unfortunately, RFC 8949 does not define an integer representation of time with sub-second precision.
To comply with RFC 8949 for CBOR tag 1, the TimeUnixMicro option encodes POSIX [TIME_T] in UTC to floating point (instead of encoding to integer).
Since floating point is a lossy format, adding TimeUnixNano can lead to flakier round-trip tests, etc.
System Time and Time Function Accuracy
System time is sometimes not as accurate as we imagine (due to OS, running inside vm, etc.). For example, see:
Also, some time-related functions might use cached time values or are affected by the OS scheduler, etc. For example, see this old Go issue caused by OpenBSD's nanosleep() & scheduler.
Another pitfall is relying on time with fractional seconds for sorting, instead of using a separate sequence number (especially on systems with concurrency that can produce events with identical timestamps).
This feature was suggested by @ssanderson at:
Currently, we have
TimeRFC3339Nanooption for encoding to CBOR time (tag 0) with nanosecond precision. However, it retains the timezone of time.Time being encoded and it can be inconvenient to settime.Timeto UTC before encoding it to CBOR.NOTE: The
TimeUnixoption (default setting) uses 1-second precision, UTC, and encodes to integer (CBOR tag 1). It is the recommended setting unless you need fractional seconds.If user apps need to encode UTC time with nanosecond precision to integer (instead of string), then that is supported by this library in the API for user-defined CBOR tags.
RFC 8949 and Time
RFC 8949 defines CBOR tag 0 and tag 1 for encoding time using integer, floating point, or string value.
Unfortunately, RFC 8949 does not define an integer representation of time with sub-second precision.
To comply with RFC 8949 for CBOR tag 1, the
TimeUnixMicrooption encodes POSIX [TIME_T] in UTC to floating point (instead of encoding to integer).Since floating point is a lossy format, adding
TimeUnixNanocan lead to flakier round-trip tests, etc.System Time and Time Function Accuracy
System time is sometimes not as accurate as we imagine (due to OS, running inside vm, etc.). For example, see:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/support-boundary-high-accuracy-time
Also, some time-related functions might use cached time values or are affected by the OS scheduler, etc. For example, see this old Go issue caused by OpenBSD's
nanosleep()& scheduler.Another pitfall is relying on time with fractional seconds for sorting, instead of using a separate sequence number (especially on systems with concurrency that can produce events with identical timestamps).