Americas

  • United States
sandra_henrystocker
Unix Dweeb

Unix, Linux and epoch time

How-To
Feb 23, 20244 mins
Linux

You can use the stat command to view dates and times associated with Linux files, and the date command can do some handy conversions if you’d like to display the current time in the epoch format.

Caucasian hand holding up four fingers. Number 4.
Credit: Krakenimages.com/Shutterstock

Working on Linux doesn’t often require that we contemplate epoch time, but the concept plays an important role in a “behind the scenes” kind of way. Epoch time is based on the number of seconds since 00:00:00 on January 1, 1970, and is used to record dates/times on Linux systems in an abbreviated format. For example, Jan 2, 1970, would have been saved as 86400 (that many seconds later than Jan 1, 1970). That’s 60 x 60 x 24 – the number of seconds in a single day. Jan 3, 1970, started at 172800 (2 x 86400) seconds after the start of Jan 1, 1970, and Jan 4, 1970, started another 86400 seconds later, and so on.

There are three dates and times associated with Linux files – the last access time (atime), the date and time when the content of the file was last modified (mtime), and the last time that the file’s metadata (e.g., file permissions) were changed (ctime). All of these dates and times are stored in the inodes that are associated with the particular files.

To view these dates and times, you can use the stat command which, in the example below, also shows the file’s “birth” time – which many versions of Linux do not report – along with the file size, owner, permissions, inode number, etc. This information is also stored in the file’s inode.

$ stat xyz
  File: xyz
  Size: 1297            Blocks: 8          IO Block: 4096   regular file
Device: 0,42    Inode: 22965       Links: 1
Access: (0660/-rw-rw----)  Uid: ( 1001/     shs)   Gid: ( 1001/     shs)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2024-02-17 10:53:45.295165033 -0500
Modify: 2024-02-17 10:59:03.335266910 -0500
Change: 2024-02-17 10:59:40.891623555 -0500
 Birth: 2024-02-17 10:03:16.379458282 -0500

While the list of the dates and times above may all look somewhat normal, they display a long string of nanoseconds (e.g., 335266910) and an indication of the time zone (-0500) associated with the date. The time zone in this example (-0500) means GMT-5 (Eastern US).

The date command can do some handy conversions for you if you’d like to display the current time in the epoch (seconds since the start of Jan 1, 1970) format. The examples below show the commands to use.

To display the current epoch time (i.e., show the date as the number of seconds since Jan 1, 1970), use the command shown below:

$ date +%s
1708187468

To convert an epoch time (seconds since Jan 1, 1970) back to the normal date/time format:

$ date -d @1708187468
Sat Feb 17 11:31:08 AM EST 2024

What about 2038?

While it may not be obvious, there is a problem on the horizon. It’s often referred to as the “Year 2038 problem” or the “Epochalypse”. While epoch time allows dates and times to be stored in a relatively trim format, it can only store so much data – especially using signed 32-bit integers. This means that some systems will be unable to represent dates and times later than 03:14:07 on January 19, 2038.

At the same time, this oncoming problem has been recognized for some time. In the last 10 years, ongoing fixes have been added. In time, APIs and interfaces may need to be modified to accept 64-bit values to be used for dates/times and file systems updated to accept 64-bit timestamps for files and directories.

Operating systems that support long 64-bit time_t are less likely to be affected by the “Epochalypse”. However, applications that use 32-bit time_t may still fail. Fixes are still evolving.

In the meantime, a nice web page for “playing with” Unix/Linux timestamps is available at the unixtimestamp page.

sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.