From thomas.braun at byte-physics.de  Sun Jul  6 18:36:42 2025
From: thomas.braun at byte-physics.de (Thomas Braun)
Date: Sun, 06 Jul 2025 20:36:42 +0200
Subject: [omniORB] omniORB: Status of 2038 compatibility with time_t
In-Reply-To: <a1897859ad2be8fc745f90304f5d441d8b015d0f.camel@grisby.org>
References: <6bfcbaf3bb709e0b9cdab3d01937f67f60496a19.camel@byte-physics.de>
 <a1897859ad2be8fc745f90304f5d441d8b015d0f.camel@grisby.org>
Message-ID: <4326588597929cf96ec3df2346c4f2517dc19bbf.camel@byte-physics.de>

Am Dienstag, dem 24.06.2025 um 10:11 +0100 schrieb Duncan Grisby:
> On Mon, 2025-06-23 at 00:02 +0200, Thomas Braun via omniORB-list
> wrote:
> 
> > While working on some code involving omni_thread::get_time() I was
> > wondering if omniORB does already support times beyond 2038?
> 
> On 64 bit Unix / Linux, unsigned long is 64 bits, so there is no
> concern at all.
> 
> On 32 bit platforms, plus all versions of Windows, unsigned long is
> 32
> bits, but it is unsigned, so it does not have a 2038 problem ? that
> applies to signed 32 bits. With unsigned, the limit is 2106.
> 
> At some point, omnithread's time handling should be changed to use 64
> bits on all platforms, but that would of course be a binary
> incompatible change that requires a major release. It is not going to
> be a problem in 2038, so there is no pressing need for it.

That's the information I was looking for.

Thanks,
Thomas