On January 19, 2038, the clocks in all embedded devices which are using Unix time, which is time in seconds since January 1st, 1970 will cease to function. This includes most if not all 32-bit Linux, or GNU/Linux, based systems, and other embedded operating systems as well. Some clocks will loop around to 1901, some will stop, and others will experience other issues, especially if the hardware tries to automatically obtain the current time from a time server. The Android OS is affected. Some iOS features are affected even on IOS 64-bit. Most, if not all, IP cameras are affected. The Raspberry PI OS is affected.
It's important understand that the Y2K38 problem technically has little to do with with whether a CPU or operating system is 32-bit or 64-bit. For the last two decades C compilers have been able to support 64-bit integers even on a 32-bit systems. It only has to do with whether the system is using the Unix time format, and if so, if the designers of the API decided to make it 64-bit or 32-bit when the API/ABI for that particular architecture was designed. BSD has used 64-bit time since the 90s. Windows was never affected, but some Windows software can still be affected if it uses the 32-bit Unix compatible time function, instead of the Windows one. Windows added 64-bit Unix time support along side the 32-bit time function since the days of Windows 2000.
The Y2K38 problem is now less than 17 years away. We have reached the point where many IP cameras will still be in use when the time comes. The clocks will have to be set back, the time sync feature will have to be turned off, and the NVR or computer that is running the DVR software may have to have its clock set back as well, as the software will try to sync the camera's clock to the computer.
I got a Hikvision camera, and the clock can't be set beyond 2038.
I got a Fuluva camera with Windows software from Amazon. The software ceases to connect to the camera if the computer clock passes 2038.
The situation doesn't look good. If anyone finds a camera that is Y2K38 compliant, please share!
It's important understand that the Y2K38 problem technically has little to do with with whether a CPU or operating system is 32-bit or 64-bit. For the last two decades C compilers have been able to support 64-bit integers even on a 32-bit systems. It only has to do with whether the system is using the Unix time format, and if so, if the designers of the API decided to make it 64-bit or 32-bit when the API/ABI for that particular architecture was designed. BSD has used 64-bit time since the 90s. Windows was never affected, but some Windows software can still be affected if it uses the 32-bit Unix compatible time function, instead of the Windows one. Windows added 64-bit Unix time support along side the 32-bit time function since the days of Windows 2000.
The Y2K38 problem is now less than 17 years away. We have reached the point where many IP cameras will still be in use when the time comes. The clocks will have to be set back, the time sync feature will have to be turned off, and the NVR or computer that is running the DVR software may have to have its clock set back as well, as the software will try to sync the camera's clock to the computer.
I got a Hikvision camera, and the clock can't be set beyond 2038.
I got a Fuluva camera with Windows software from Amazon. The software ceases to connect to the camera if the computer clock passes 2038.
The situation doesn't look good. If anyone finds a camera that is Y2K38 compliant, please share!
Last edited:
. Most of my cameras are a year or two old now, if not older. A few must be close to 5-6 years now.
