4 ms·
I'd like to add one to the list - store your Unix time as a 64-bit value, to save your client/employer some headaches in 2032. I doubt I'm the only HN user who
by projectileboy 15y ago
I'd like to add one to the list - store your Unix time as a 64-bit value, to save your client/employer some headaches in 2032. I doubt I'm the only HN user who was spent a lot of time in '98 and '99 fixing Y2K problems.
- caf 15y agoPersonally I'm looking forward to cashing in on some lucrative contracts as a graybeard C programmer in 20 years time, the same way all those COBOL survivors were able to in the late 90s ;)
- mambodog 15y ago*2038 http://en.wikipedia.org/wiki/Year_2038_problem http://en.wikipedia.org/wiki/Year_2038_problem
- projectileboy 15y agoD'oh! I misfired typing. Thanks for the correction.
- masklinn 15y ago> I'd like to add one to the list - store your Unix time as a 64-bit value How about actually doing the right thing and using time_t?
- nuxi 15y agoI'm not sure that's the right thing, due to how time_t is (not) defined. First, it can be an integer or a floating number (although the latter is unlikely). Second, the size of time_t is not defined, so it could be 32-bit or 64-bit or something else. And then there may also be endianness issues when storing time from multiple different systems. So I'd say store it either as a 64-bit value (ignoring the possible floats, converting 32- to 64-bit and handling endianness), or use a textual representation of time_t.