# Optimizing UTC -\> Unix Time Conversion For Size And Speed

DevFeed: [Optimizing UTC -\> Unix Time Conversion For Size And Speed](<https://devfeed.tech/articles/optimizing-utc-unix-time-conversion-for-size-and-speed-21133.md>)

Original publisher: [Read original article](<https://blog.reverberate.org/2020/05/12/optimizing-date-algorithms.html>)

Author: Haberman

Published: 2020-05-12T00:00:00Z

Content type: article

Language: en

Sources: [Josh Haberman](<https://devfeed.tech/sources/josh-haberman.md>)

Topics: [Algorithm](<https://devfeed.tech/topics/algorithm.md>), [C](<https://devfeed.tech/topics/c.md>), [JSON](<https://devfeed.tech/topics/json.md>), [Unix](<https://devfeed.tech/topics/unix.md>), [Parser](<https://devfeed.tech/topics/parser.md>), [Fortran](<https://devfeed.tech/topics/fortran.md>)

Tags: [algorithm](<https://devfeed.tech/tags/algorithm.md>), [c](<https://devfeed.tech/tags/c.md>), [function](<https://devfeed.tech/tags/function.md>), [json](<https://devfeed.tech/tags/json.md>), [library](<https://devfeed.tech/tags/library.md>), [linux](<https://devfeed.tech/tags/linux.md>), [speed](<https://devfeed.tech/tags/speed.md>), [standard](<https://devfeed.tech/tags/standard.md>), [systems](<https://devfeed.tech/tags/systems.md>), [time](<https://devfeed.tech/tags/time.md>), [unix](<https://devfeed.tech/tags/unix.md>)

## AI overview

This article examines converting UTC calendar timestamps to Unix Time without relying on non-standard library functions. It explains leap-year handling and discusses a compact, portable C algorithm used for the upb JSON parser, including its size and speed characteristics.

## Source excerpt

How do you convert a UTC timestamp to Unix Time (seconds since the epoch)? "2020-04-29 04:48:15" -> 1588135695 Of course the right answer is "you use a standard library function." But what if you don't have one available? Or what if you're the person implementing that library? Converting the time portion is trivial. Unix Time pretends that leap seconds do not exist and makes every day exactly 86,400 seconds long. This is a fib on systems that implement UTC leap second insertion1, but it makes the algorithm very simple: time_t hms_to_time(int h, int m, int s) { return (h * 3600) + (m * 60) + s; } But the calendar part is more challenging. Months have unequal lengths, and leap years complicate everything. Leap years insert an extra day at the end of February whenever: the year is divisible by four excluding years divisible by 100 but including years divisible by 400 Surprisingly, no version of C includes a UTC -> Unix Time conversion function in the standard library. There is a non-standard function timegm(), but its use is discouraged. The Linux manpage says: These functions are nonstandard GNU extensions that are also present on the BSDs. Avoid their use. And on BSD: The timegm() function is not specified by any standard; its function cannot be completely emulated using the standard functions described above. I needed an algorithm to perform this UTC->UnixTime conversion for the JSON parser in upb. The JSON mapping for Protocol Buffers says that timestamps are formatted using strings like: 1972-01-01T10:00:20.021Z Once we have parsed the individual numbers out of such a timestamp string, we need a way of translating to seconds since the Unix Epoch, which is the internal representation of the google.protobuf.Timestamp type. Since upb is written in C and intended to be portable, I needed to roll my own. Since upb aims to be as small and fast as possible, I became very interested in the problem of how far this algorithm could be pushed in size and speed. A Fortran Solutio