So I was reading about the Year 1997 problem with Domain/OS and saw mentions of a Year 2014 problem with UIDs.
Then I read http://bitsavers.trailing-edge.com/pdf/apollo/AEGIS_Internals_and_Data_Structures_Jan86.pdf and realized that UIDs had a 36-bit field containing creation time.
It is an integer that use 16 ms as the unit and January 1, 1980 as the epoch, which means it will overflow on Mon Nov 03 2014 19:53:47 UTC.
Hopefully the OS deals with this gracefully and duplicate UIDs will not occur unless there are UIDs created in 1980.
In addition, Apollo Domain/OS use a 48-bit integer (clock_t) with units of 4 microseconds to represent current date/time.
This value reached 2^47 on Sun Nov 02 1997 14:59:13, which caused problems with portions of the OS that treat this integer as signed. HP released patches for this back in 1996.
I would like to warn that this value will reach 2^48 on Sat Sep 05 2015 05:58:26 UTC. This problem can't be fixed without changing the epoch (Jan 1, 1980) or increasing the size of the type.
Then I read http://bitsavers.trailing-edge.com/pdf/apollo/AEGIS_Internals_and_Data_Structures_Jan86.pdf and realized that UIDs had a 36-bit field containing creation time.
It is an integer that use 16 ms as the unit and January 1, 1980 as the epoch, which means it will overflow on Mon Nov 03 2014 19:53:47 UTC.
Hopefully the OS deals with this gracefully and duplicate UIDs will not occur unless there are UIDs created in 1980.
In addition, Apollo Domain/OS use a 48-bit integer (clock_t) with units of 4 microseconds to represent current date/time.
This value reached 2^47 on Sun Nov 02 1997 14:59:13, which caused problems with portions of the OS that treat this integer as signed. HP released patches for this back in 1996.
I would like to warn that this value will reach 2^48 on Sat Sep 05 2015 05:58:26 UTC. This problem can't be fixed without changing the epoch (Jan 1, 1980) or increasing the size of the type.