1

How to use the mktime64() in Linux with 32-bit time library to avoid the year 2038 issue?

We have tried using the macro _Time64 but failed as compiler still throws undefined mktime64() error:

typedef long long _Time64_t;

_Time64_t _Time64(_Time64_t *pt);

struct tm *_Localtime64(_Time64_t *pt);

_Time64_t _mktime64(_Time64_t pt);

main.c:(.text+0x68): undefined reference to `_mktime64'

Could you please help me how to use the mktime64, time64 and localtime64 function using 32-bit library?

phuclv
  • 37,963
  • 15
  • 156
  • 475
Gaurav_is_lucky
  • 11
  • 4
  • 1
    What is your OS? – Ruslan Jul 25 '19 at 09:37
  • There's a **Microsoft Windows** specific function named `_mktime64()` but I can't find any reference to such a thing in the usual **Linux** libc implementations. – Shawn Jul 25 '19 at 12:23
  • 1
    What documentation are you looking at that suggests that you can use functions by those names on a Linux system? And does it say to use your own prototypes like you seem to be doing instead of getting them via including a header file? – Shawn Jul 25 '19 at 12:27
  • Can you post a [MCVE]? – Tim Jul 25 '19 at 23:10

2 Answers2

2

C standard libraries (CRT) on Linux only has one time_t type so there's no _mktime64 for you

On 32-bit Windows there are 2 different time_t types (__time32_t and __time64_t) and 2 versions of each time functions (like _mktime32 and _mktime64) just because Microsoft gradually added 64-bit time support to their CRT without breaking old code. Standard identifiers like time_t or mktime are actually macros that will be defined as the desired 32 or 64-bit version. time_t was changed to 64-bit by default in VS2015 so all apps compiled since then will not suffer from year 2038 problem. For more information read Another look at the year 2038 problem

Linux CRTs address the year 2038 issue by changing time_t to a 64-bit type immediately without any gradual intermediate steps. That happened in 64-bit Linux immediately since the first build. But in 32-bit Linux it happened much later, only since 2020 with glibc 2.32+ and musl 1.2+ running on Linux kernel 5.6 or newer. So to avoid the year 2038 issue on 32-bit Linux you must be on a new enough kernel and CRT

  • All user space must be compiled with a 64-bit time_t, which will be supported in the coming musl-1.2 and glibc-2.32 releases, along with installed kernel headers from linux-5.6 or higher.
  • Applications that use the system call interfaces directly need to be ported to use the time64 syscalls added in linux-5.1 in place of the existing system calls. This impacts most users of futex() and seccomp() as well as programming languages that have their own runtime environment not based on libc.

https://lkml.org/lkml/2020/1/29/355?anz=web

If you can't upgrade the CRT and kernel version then you need to use a 3rd party library like evalEmpire/y2038, but obviously when it comes to the actual 2038 the library might not be able to get the real system time from the kernel. Hopefully you don't use such ancient kernels at that time

This is an implementation of POSIX time.h which solves the year 2038 bug on systems where time_t is only 32 bits. It is implemented in bog-standard ANSI C.

If your kernel version is between 5.1 and 5.6 then you can also write your own wrapper functions because 64-bit time support on 32-bit platforms was introduced to the Linux 5.1 kernel with the addition of the new *time64 syscalls

For more information read

phuclv
  • 37,963
  • 15
  • 156
  • 475
0

These functions seem to be Microsoft only

ruipacheco
  • 15,025
  • 19
  • 82
  • 138