Re: [Hamlib-developer] Year 2038 issues

[Black M. <mdb...@ya...>]

The only problems I see is setting the clock on rigs as that uses system time and the multicast packets would have the wrong time too.
Also the times in the debug output is not really a problem with operations but will be wrong.


I'll have to grab a 32-bit OS image and do some testing.

I can imagine capturing the time functions and adding an offset to them if that's needed.   That could be done by libc if they implemented that.

Mike W9MDB







On Saturday, January 20, 2024 at 07:19:53 AM CST, Nate Bargmann <n0...@n0...> wrote: 





* On 2024 20 Jan 04:03 -0600, "C. van Wüllen" wrote:
> I remember well all the cassandras warning for the „Y2K“
> proble - - and nothing happened.

Nothing happened because the prior several years were spent
testing/fixing/replacing problematic systems.  It was a real thing not
to be discounted despite the irresponsible media hype and the liars and
thieves y2k gathered along the way, particularly the past 18 months or

so.


I recall the 2038 issue being raised not long after y2k had passed.  Of
course, some responses were along the lines of "38 years?  We have
plenty of time..." and now 24 of those years have passed and ideas are
still being debated on the best fixes.  In light of that, 14 years will
go by quickly.

Mike has opened an issue:

https://github.com/Hamlib/Hamlib/issues/1478

This will probably be a long running issue as making sure the code base
as it exists today is compliant is not enough but also that future
commits don't introduce regressions.

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819


_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer