64-bit Unix time
Consider upgrading from 32-bit Unix time to 64-bit Unix time so that PI can support dates past January 19, 2038. Reasons:
This date is fast approaching as a future value. It is only 20 years away.
OSIsoft will need time to implement the 64-bit time stamps and convert all existing and supported PI Data Archives to use the 64-bit time stamps. At least a year of time will be used up for leeway.
Once 64-bit Unix time is implemented, then OSIsoft can exclude from training presentations the (very high) upper limit of supported time. This gives the user 1 less thing to worry about.
It gives 1 less thing for OSIsoft to have to remember for the future.
Rick Davin mentions an interesting solution to the Year 2038 problem in his long comment here:
He suggests using ticks, which are also 64-bit. Unlike 64-bit Unix time, where an increment of 1 represents 1 second, an increment of 1 tick represents 100 nanoseconds. 64-bit Unix time reaches billions of years into the future and doesn't support subseconds, whereas ticks reach only thousands of years into the future but do support subseconds.
Ticks, or some other format that reaches far into the future and supports subseconds, might be the better choice.
Steve Boyko commented
Many of us lived through Y2K. Let's be proactive and fix this well before it's needed. There shouldn't be any 32 bit dates in PI archives.
Since this suggestion will likely require a change to the existing archive format, it would be a good chance to implement these as well:
This website below counts down the time until the Year 2038 problem:
As of right now, it is 17.5 years. However, OSIsoft has much less time to fix the issue. As I mentioned, we probably want at least 1 year of leeway. Development might stretch out to, say, 2 years. It might take 5 years before almost all customers are migrated to a version of the PI Data Archive that uses 64-bit time. If we ignore utility companies (which we shouldn't!), most companies probably have future data going at most 1 year into the future.
This means that OSIsoft should start working on this in late 2028 at the absolute latest, which is only 8 years away, to avoid the Year 2038 problem. Of course, if OSIsoft cares about the 20-year forecasts of companies that do them, they should start working on this as soon as possible.
Michael Tippett commented
To build upon this, it is not at all uncommon for utility companies to have 20 year forecasts for data. The current PI system will no longer be able to meet this requirement as of next year. So whilst 2038 seems like a long way away it is closer than we think.