Re: [Hamlib-developer] Year 2038 issues

[Greg T. <gd...@le...>]

Nate Bargmann <n0...@n0...> writes:

> Early this morning at 03:14:07 UTC the time remaining until the Unix
> Epoch rollover where the signed 32 bit count of seconds since 01 Jan
> 1970 00:00:00 UTC is just under 14 years.  Certainly, that is a long
> time off, but, Hamlib is now 23 1/2 years old!
>
> I have not looked deeply, but it may be useful to ensure that Hamlib contains
> no problematic uses of time_t or anything that uses the 32 bit signed integer
> of the Unix epoch.  I see the following:

Briefly, I think it's a bug of an operating system to be using a 32-bit
type for time_t, and that systems should either change that type to
e.g. int64_t or expect people to migrate away from them.   In NetBSD, we
changed time_t from a historical type that was 32 bits to int64_t over
10 years ago, and versioned interfaces for binary compat.

So for hamlib, the correctness condition is to not store a time_t in any
other type, and when using it with printf, not to assume that it's %ld.


I think it would be regrettable to put in workarounds for systems that
have unsuitable time_t types.

73 de n1dam