Post by Tim Blechmanni am curious, how are osc timetags supposed to handle the overflow of the 32bit
unix time in 2038? afaict, it is not possible to change the size of the timetag
to avoid the overflow breaking the binary representation of bundles.
Hi. Yes you are correct, the overflow breaks the representation, similar to the infamous Y2K bug there will be a Y2037/Y2038 bug as various legacy 32-bit systems cause airplanes fall from the sky and whatnot.
A curious fact is that the NTP format does not have a 1:1 mapping of timestamp values to actual moments in time. Specifically it doesn't count leap seconds, which occur unpredictably, so in general its not possible to compute the elapsed time between two arbitrary timestamp values.
Therefore (in my opinion), NTP format can't be regarded as a reliable historical record, so there isn't much harm in letting in wrap around.
Furthermore, most real-time protocols that similarly encode a presentation time (e.g., AVB) use significantly fewer bits than are called for in OSC, and those wrap around frequently (like, once per week). A bit of phase-unwrapping logic is required to implement such systems and generally the maximum allowed future scheduling window is one half of the available timestamp values. In practice the future window needs only to be long enough to account for network delays and expecting systems to have huge buffers to queue events in the distant future isn't practical.
OSC also effectively reserved the least significant bit of the timestamp by means of the "immediate" convention, reducing the effective precision from 200 to 400 picoseconds.
---
Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu
skype: andy.schmeder
Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu