System calls

interfaces that uses relative time_t/timespec/timeval These can stay compatible, but we'd have to use a different type if we change time_t.



getrusage (+ wait4?)




Also: futex, recvmmsg, io_getevents?

interfaces that don't make sense for times in the past Here, we are relatively free to change the start of the epoch in the kernel but convert to something else on the user space boundary. One possibility is to scale them to boot time and use ktime_t in the kernel.

[Does checkpoint/restore have any implications here wrt to how freely we can change the start of the epoch? E.g., when freezing/restoring processed from different systems that have timer_settime() timers?]


timer_settime/timer_gettime(+timerfd_settime, timerfd_gettime?)



clock_gettime/clock_settime/clock_adjtime/clock_nanosleep(? what about clock_nanosleep TIMER_ABSTIME?)


sysv ipc (msg, sem, shm)


interfaces that require absolute times These absolutely have to use something better than time_t both in user space and in the kernel so we can deal with old files. A lot of file systems need to be fixed as well so we can actually store the times, regardless of whether we are running a 32 or 64 bit kernel.



ioctl There are numerous ioctl commands using a time argument. This list is incomplete

audio time stamps

v4l time stamps

input event time stamps

socket time stamps


memory mapped packet sockets Socket timestamps are exported to user space using a memory mapped interface defined in include/uapi/linux/if_packet.h. There are currently three versions of this interface, all use a 32-bit time type. We will likely need a version 4 to solve this.

Audit of include/uapi for time_t impact Structure and IOCTL dependency:


Syscalls affected by the above types:

KernelNewbies: y2038/syscalls (last edited 2017-12-30 01:30:12 by localhost)