# On timestamping **URL:** \ **Category:** Development & Maintenance\ **Created:** [November 11, 2018, 1:57am UTC](https://forum.opencyphal.org/t/on-timestamping/237 "2018-11-11T01:57:00Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [November 11, 2018, 1:57am UTC](https://forum.opencyphal.org/t/on-timestamping/237/1 "2018-11-11T01:57:00Z")
There have been [reports that the current approach to timestamping is too wasteful](https://github.com/UAVCAN/dsdl/issues/34#issuecomment-333929242), as every timestamp is represented by a large 56-bit wide unsigned integer. There have been suggestions to utilize a more compact form for the sake of lower transfer fragmentation, lower bus load, and lower latency. The reason why we use large 56-bit timestamps is because they provide an unambiguous context-independent representation of a point in time. A 56-bit timestamp value contains an immediately usable value that never expires and is always valid. As we are [beginning to rely on timestamping heavily](https://forum.opencyphal.org/t/si-namespace-design/207/7), I would like to resurrect this discussion once again to have this question settled for UAVCAN v1.0. Let us discuss the advantages and disadvantages of smaller overflowing expirable timestamp representations. I would like to avoid talking about representations that offer a reduced resolution (lower than one microsecond) for reasons of consistency and avoiding introduction of new restrictions on application design (a message that relies on a compact timestamp may also require full microsecond resolution). The standard 56-bit microsecond timestamp would overflow in 2284 years, which means virtually never. A reduced 32-bit microsecond representation would overflow in 1 hour and ~12 minutes while being 24 bit shorter and introducing an additional computational burden on the application. Neighboring byte-aligned representations (namely, 24-bit and 40-bit) do not seem to be worth the effort as one of them would overflow too frequently (16 s), and the other does not offer a significant improvement over the full timestamp (being only 16 bit shorter). The following calculation does not show any improvement for 32-bit timestamps with CAN FD, as the freed up space would be used by padding bytes anyway: > [@SI namespace design](https://forum.opencyphal.org/t/si-namespace-design/207/7): > > 32-bit values with 56-bit timestamps work well with CAN FD: 32-bit payload + 56-bit timestamp + 8-bit tail byte = 96 bits = 12 bytes, which corresponds exactly to the DLC code 10012. Same is true for 3-element vectors: (56 + 32 \* 3 + 8) / 8 = 20 bytes, DLC = 10112, no padding bytes necessary. Do we want this? --- _[View the full topic](https://forum.opencyphal.org/t/on-timestamping/237)._