timestamp sensor 32-bit? year 2038 overflow?

[scottcopus]

Sorry, I'm new to BTHome and just want to make sure the timestamp is futureproofed.

Is the timestamp sensor a 32-bit or 48-bit number?
https://bthome.io/format/ says "uint48 (4 bytes)" which seems ambiguous, unless I'm misunderstanding the info.

If it's only 32-bit, then it'll overflow in 2038! https://en.wikipedia.org/wiki/Year_2038_problem

BTW, it might be a good idea to add webpage #anchors to all BTHome.io webpages that have multiple/long sections to them so it's easy for someone to deep-link.

[Ernst79]

It’s 4 bytes, excl. the byte for the sensor type. I see I made an error in the table, the example should be 0x50 5d396164, so 4 bytes (unsigned) following 0x50 for timestamp. I have updated the example.

With 0x50 ffffffff We get 4294967295 as integer, which is Sunday 7 February 2106 06:28:15 in epoch time as maximum date. So, no 2035 bug, but a 2108 bug, but I assume we can live with that.

[scottcopus]

Ah, I didn’t recognize that timestamp was also unsigned which helps it last a bit longer. ;) If this is acceptable by other devs in the general HA world, I’m good with it.

[Ernst79]

By the time we get close to 2108 I’ll add a 5 byte long timestamp, if I still live. Help me remember by that time 😄

[miri64]

Saw this issue but I am still not clear, why the table says uint48 (4 bytes). uint48 would be 6 bytes but all examples (and the parenthesis) hint at 4 bytes so uint32.