Converting To and From Unix Timestamps with C#

From time to time it's necessary to convert Unix timestamps. These C# methods will do just that and make interacting with Unix easy.

From time to time it is necessary to convert to and from Unix timestamps, mainly when dealing with system interoperability. These timestamps are an accurate measure of time from a given point and have a simple data type.

Instead of a date and time, Unix (and Linux) timestamps store a number. This is the number of seconds that have passed since 00:00:00 Coordinated Universal Time (UTC) on Thursday, January 1, 1970. Because leap seconds are not included in Linux timestamps, they aren't comparable to real-time.

When displaying a timestamp, Linux converts the number of seconds into a date and time. This is simply to help humans understand the number. The conversion to a date and time is guided by the location and time zone of the device that is accessing the number. It also ensures that the day and month are displayed in the relevant language.

These two functions will convert a .Net DateTime into a Unix timestamp and vice versa.

public static DateTime ConvertFromUnixTimestamp(ulong timestamp)
{
    DateTime origin = new DateTime(1970, 1, 1, 0, 0, 0, 0);
    return origin.AddSeconds(timestamp);
}

public static double ConvertToUnixTimestamp(DateTime? date = null)
{
    DateTime origin = new DateTime(1970, 1, 1, 0, 0, 0, 0);
    TimeSpan diff = (date ?? DateTime.Now) - origin;
    return Convert.ToDouble(Math.Floor(diff.TotalSeconds));
}

Year 2038 Problem

There are however limitations to the current implementation of Unix timestamps. On 32-bit data types, the date time 03:14:07 UTC on 19 January 2038 represents the maximum value an integer can hold. One second after this and the time will rollover, back to 1970. This is the second coming of the millennium bug. This is also known as the Y2K38 superbug or the Epochalypse.

Any system that uses data structures with 32-bit time representations is doomed to fail. A complete list of these data structures is very impossible to compile, but some well-known data structures suffer from the Unix time problem:

• Many file systems utilise only 32 bits to express times in inodes.
• Binary file formats (with time fields of 32 bits)
• Databases with 32-bit time fields
• Database query languages using UNIX_TIMESTAMP()-like commands (such as SQL)

The Unix time_t data type represents a point in time that is, on many platforms, a signed 32 bits integer. Most operating systems built for 64-bit hardware already make use of signed 64-bit time_t integers which have a new wraparound date that is more than twenty times bigger than the universe's estimated age: around 292 billion years from now.

The Year 2038 problem has no universal answer. In the C, any change to the specification of the time_t data type would cause code-compatibility issues in any application where the date and time representations are dependent on the nature of the signed 32-bit time_t integer. Changing time_t to an unsigned 32-bit integer, for example, which would expand the range to 2106 may have a severe impact on programmes that save, retrieve, or modify dates before 1970, because such dates are represented by negative values. In an existing system, increasing the size of the time_t type to 64 bits would result in incompatible changes to structure architecture and function binary interface.