Time, Clock, and Calendar Programming In C

These functions are the poster children for the mess created by having multiple time representations. All three simply delay execution of the calling program for some span of time; what differs is how that time is specified.

The oldest, sleep(3), takes an integer argument in seconds; usleep(3) takes microseconds, and nanosleep(3) takes a struct timespec with nanosecond resolution. All three may be interrupted by an unignored signal. The nanosleep(2) function takes a second timespec which is filled with time remaining if it was interrupted.

The usleep(3) call originated in BSD Unix and, though it was carried forward in POSIX, was deprecated in favor of nanosleep(2) in POSIX.1-2001/SUSv3 and then removed entirely in POSIX.1-2008/SUSv4. It’s probably best not to count on it being portable.

Of these three functions, only nanosleep(3) is guaranteed not to have any interaction with signals (the other two may be implemented using some signal and a hidden handler). It is is thread- and signal-safe.

The sleep(3) function is required by POSIX to be async-signal-safe and thread-safe. The thread-safe requirement means sleep(3) can’t be signal-based in multithreaded programs, but can be in single-threaded programs.

These functions should not be mixed with the ones in the next group.

The alarm functions are another case of call proliferation due to multiple time units. The oldest, alarm(2|3), sends SIGALRM after a specified number of seconds; ualarm(3) sends SIGALRM after a specified number of microseconds (and a second argument, if nonzero, causes SIGALRM to be sent at regular intervals afterwards).

The getitimer() and setitimer() functions come from the Single UNIX Specification before 1996, when SUSv2 was merged with POSIX.1-1996 to develop POSIX.1-2001/SUSv3. They are now deprecated in favor of the POSIX timer_* calls in the next section.

These have three advantages over the traditional alarm calls: (1) they use timeval structures, so have microsecond resolution; (2) they can trigger the sending not just of SIGALRM but of more specialized profiling signals; and (3) they give you options about what derivative of the system hardware clock you want to use.

The gory details about the interval timer functions are best learned from their manual pages. For our purposes, the important thing to cover is how they fit with the rest of the time and calendar API. Bluntly, that is not very well.

The manual pages are full of ominous "unspecified behavior" warnings if you mix uses of the sleep group, the alarm group, and the itimer group in the same program. The reason for this is historical.

The sleep and alarm function groups developed by accretion in early Unixes. The sleep(3) group was often implemented with alarm(3) and a specialized SIGALRM handler; likewise for usleep(3) and ualarm(3).

The itimer functions were the result of a later effort to specify a more general facility that could subsume these, starting from a clean sheet of paper. They were declared obsolete in POSIX.1-2001/SUSv3 in favor of the timer_* group.

Thus, it is possible that your system’s implementation of sleep and alarm functions is a thin layer over POSIX itimer calls (or, possibly, the timer_* group documented next) using the ITIMER_REAL clock. When that isn’t the case, legacy implementations of the sleep and alarm calls won’t necessarily play well with interval timers - in particular SIGALRMs might be flying around when you don’t expect it, or setting an implied signal handler through the sleep functions might be interfered with by setitimer(2|3).

It’s best not to go there. Heed the warnings and don’t mix up these function groups.

There is a group of POSIX functions timer_create(2|3), timer_delete(2|3), timer_settime(2|3), timer_gettime(2|3), and timer_getoverrun(2|3) that can be used to set per-process interval timers even more flexibly than the itimer group. In particular, they allow setting a function-call hook to be called directly at the end of an interval without going through either an explicit or implicit signal.

These functions were introduced in POSIX.1b-1993. After POSIX and SUSv2 merged in 2001 getitimer(2|3) and setitimer(2|3) were declared obsolete.

Neither the native Linux nor POSIX man pages document interactions with the older calls. A prudent programmer should assume that the alarm and sleep group is implemented in terms of one of the two groups of newer POSIX interval-timer functions, and not mix any of them.

If you want to avoid interval variability due to NTP frequency adjustments, you probably want to use these with CLOCK_MONOTONIC.

These functions are Linux-specific (not standardized), offering a way to monitor timer expiration via selecting or polling on a file descriptor rather than via signal handler.

They are mentioned here for completeness, but should be avoided in code intended for portability. Consult the Linux manual pages for details.

A full discussion of the select(2) and pselect(2) system calls would be beyond the scope of this document, as they are not used for time/calendar programming. We mention them only to note two points:

The most basic function is time(3), which returns the current Unix second. All the previous caveats about leap-second discontinuities and tiny variabilities due to NTP correction apply.

The function difftime(3) attempts to return the elapsed time between two time_t counters as a double - however, it is not aware of leap-second discontinuities (a fact the man page does not document!).

This call was added in C89 as a way to encapsulate time arithmetic on operating systems where time_t is not a normally encoded integral or float type; it is possible (even likely) that no such environments actually exist.

While on POSIX systems where time_t is required to be an integral type holding a count of seconds it might appear equivalent to just subtracting the first argument from the second, it is not quite superfluous. It is defined to handle correctly some edge cases where naive subtraction would cause an integer overflow.

We mention the function clock(3) here only for completeness, because it is declared in time.h. It is little used, returning an approximation of processor time used by the running program. This return is not a time_t, but an integer in microseconds * CLOCKS_PER_SEC (the latter being a constant in <time.h>)

This function is very portable, but you probably want the finer-grained statistics from getrusage(2) instead.

These are the two oldest Unix interfaces that deal with subsecond time, dating from 4.2BSD (the other being ftime(3)). With them you can get time since the epoch to microsecond precision (it uses a struct timeval, not the newer struct timespec), or (with root permissions) set the system clock to microsecond precision.

Though restricted versions were carried forward in POSIX, these calls are obsolete, and are documented here mainly so you’ll understand how they fit in when reading old code. It is best to use clock_gettime(2) and clock_settime(2) (which support nanosecond precision) instead of these.

(Some systems may still require you to use gettimeofday(3); notably this is true of Mac OS X up to and including 10.9.5 Maverick, which conforms to POSIX.1-2001/SUSv3 rather than the POSIX.1-2008/SuSv4 in which clock_gettime(3) became mandatory. clock_gettime() did become part of the Mac API at 10.12 as of September 2016.

In the POSIX documentation, behavior if the gettimeofday(3) historical second argument is non-null is undefined. The Linux native gettimeofday(2) (and possibly other implementations) attempts to preserve more of the original BSD semantics, returning some timezone-related information; however, this feature is marked obsolete and should not be relied on.

The settimeofday(2) call was never standardized at all, though it was carried forward in System V Release 4 and de-facto standard for some time.

These are the modern, POSIX-standardized functions for interacting with the system clock at subsecond precision. They use the nanosecond-precision struct timespec and allow working with multiple clocks.

The most interesting (and only portable) clocks are identified as CLOCK_REALTIME and CLOCK_MONOTONIC. CLOCK_REALTIME is the familiar UNIX time since the epoch, with leapsecond discontinuities and NTP adjustments. CLOCK_MONOTONIC is a monotonically increasing nanoseconds and seconds counter that cannot be set; note that unlike an interval timer it is subject to leapsecond discontinuities and NTP adjustments.

The call clock_getres(2) is available to query the actual resolution of the system clock.

Before the mid-19th century, clocks were set (more or less haphazardly) to indicate local solar time. The goal was essentially for noon to coincide with the average time of the Sun’s maximum declination. Humans moving by foot, horse, or ship did not move quickly enough to make time synchronization between regions with different mean solar times a problem (with a very limited technical exception for marine navigation).

The impetus for standard time came from rail travel. The railroads needed standardized time in order to set and publish precise schedules
[In the mid-19th-century British clocks were sometimes made with two sets of hands, one for mean solar time and the other for railroad time.]
. While there were significant commercial advantages to adopting railroad time as a civil standard wherever it reached, human beings did not want to give up rough synchronization of their clocks and watches to local mean solar time.

Time zones developed as a compromise. By partitioning the globe into hour-wide longitudinal bands with a fixed time offset from one world reference time, two desirable properties could be achieved. First, rough synchronization with mean solar time would be maintained everywhere. Second, the relationship between standard time and any local time would remain easy to compute.

The actual time zone system never approximated this ideal very closely. Adoption was slow and patchy after the development of the first railroad standard time system (in 1847 in Great Britain) and was not roughly complete until the early 20th century.

From the beginning, various time authorities showed a tendency to move timezone borders to avoid putting regions they were closely tied to off into a different timezone, even if that meant accepting large clock deviations from mean solar time in outlying regions. Some regions adopted half-hour or even quarter-hour offsets. These meant, unhappily for computer programs and programmers, that the time offset of a location is not a simple function of its longitude.

Worse, the time zone system has been unstable over time as the political and commercial pressures on it resulted in frequent changes to the definitions of zones. And still worse than that was the partial and unstable adoption of Daylight Saving Time, aka DST, aka Summer Time, in which the time definition within a zone endures further changes, by another hour twice a year, so people get up an hour earlier and thus get an extra hour of daylight in the evening.

As a final wrinkle, some jurisdictions use different timezone names when DST is in effect; this is common in the U.S. where, for example, the Eastern timezone uses Eastern Standard Time (EST) as its basic designator but Eastern Daylight Time (EDT) during summer months. But this is not necessarily true everywhere.

More historical details can be found at [TIME-ZONE]. The result of this mess is the following:

For an entertaining video lecture about the messy consequences of this history, see [COMPUTERPHILE]. As he says near the end, your only sane option (assuming you don’t go the everything-is-UTC route) is to trust that tzdata or whatever other timezone history your operating system subscribes to is properly maintained and then simply refuse to worry about that level of the problem, because you’d go mad if you tried.

In the earliest Unixes, a machine could handle exactly one timezone other than UTC. A timezone offset and name string (actually, a pair of name strings, one for summer and one for winter time) were configured into the kernel and available to C programs.

Later (by System III in 1982) it became possible to set a login session’s notion of the local time zone by modifying an environment variable named TZ and calling a function tzset(3). The rules for interpreting the zone specification in the value of TZ became part of the POSIX standard. They were complex [OLDTZ] and now mainly of historical interest. We mention this history mainly because it has left remnants in the manual pages - notably of tzset(3) - that may confuse the uninformed reader about what is going on.

V7 and older BSD Unixes had various other methods for configuring the local timezone that didn’t involve using or interpreting TZ. These have left no traces on modern Unixes. They shared a fatal flaw with POSIX TZ interpretation, which was that they weren’t designed to cope with the historical instability of the timezone system. They could not express an entire set of historical offset/DST rules in order to get past local times as well as present ones correct.

On modern Unix systems the TZ variable might not be set at all, but the system default timezone can be overridden by explicitly setting TZ in any process. The timezone designator configured at boot time, or via an overriding value of TZ, is a geographical location (usually but not always an area/major-city pair) such as "America/New_York", or "Europe/Vienna" or "Asia/Taipei". If the designator is set via TZ it may need to be preceded by a colon; this is for backwards-compatibility with the POSIX standard, to distinguish it from an old-style timezone specification. (Not all implementations enforce this.)

The location-based zone naming scheme [IANA-ZONES] is managed by IANA, the Internet Assigned Numbers Authority. It is intended to supersede (in computing, anyway) the system of customary names we’ll refer to later in this document as "civil timezone names".

Civil timezone names such as EST/EDT are ambiguous: they have name collisions in different countries, and some civil zones have multiple names. They tend to be short (at least under Unix/Linux, though not necessarily under Windows). They may change without notice. Some of them are official (in that they appear in officially-approved legislative documents in the jurisdictions where they apply), but many of them reflect mere ad-hoc conventions.

The IANA names, on the other hand, are intended to be unique, future-proof, and for use by system administrators and knowledgeable users to set the time zone they wish to apply.

IANA timezone designators are looked up through a locally-installed copy
[The IETF is working on a protocol for pushing updates of the databases over the Internet.]
of a time zone database ("tzdata") maintained by IANA, the Internet Assigned Numbers Authority [TZSOURCES], [TZDATA]. You may hear the name "Arthur David Olson" used in connection with this database; he was the founding contributor.

The contents of the database entry for the designator describe the history of the zone name, zone offset and the DST start/end times (if any) for the location, as those have changed over time since 1970
[The IANA database used to try to cover pre-1970 history as well, though some of this is being phased out since they have learned that their primary source for very old time zone history - a book on astrology - just made some stuff up.]
. The timezone system is sufficiently chaotic in ways previously noted that some of the comments on this history make entertaining reading.

The Unix time API evolved when many system designers and software standardizers were still trying to hang on to named timezones, which were thought to be more human-friendly. Internet protocols evolving around the same time, however, abandoned named timezones early.

The results of this history are visible as a plethora of different date presentation formats. Thus, for example, the output of the Unix date(1) command looks like this: "Wed Sep 24 15:32:27 EDT 2014" (with named timezone), while a date in an SMTP mail header is more likely to look like this: "Wed, 24 Sep 2014 15:32:27 -0400" with an hhmm numeric offset.

Here is a table duplicating this example in a number of presentation formats commonly found on Unix systems:

Of these, the last is the most recent and (so far) least widely adopted presentation format; ISO-8601 was not promulgated until 1988 and RFC-3339 not published until 2002 [ISO-8601], [RFC-3339]. However, it has the best properties of any (human readability, non-ambiguity, compactness, fixed length, single token, string sort order matches time order) and we strongly recommend it.

All of these presentation formats are straightforwardly constructible using the strftime(3) function which we’ll be meeting in a few paragraphs (although parsing them can be trickier).

(See also Randall Munroe’s ISO 8601 and Supervillain Plan.)

Some Unix time API functions deal in numeric zone offsets, others in named timezone and DST. Still others (generally older ones) evade the whole issue by not reporting timezone at all. We will be more specific when we discuss individual calls.

Just to add to the hilarity, the IANA database, RFC-822/RFC-2822 dates, and Unix date(1) consider offsets east of Greenwich to be positive and west of it to be negative, but POSIX time-zone formats inexplicably reversed this.

The representation of timestamps in electronic mail has evolved through five IETF RFCs. We also include the USENET bulletin-board system (which used email-like headers) in this sequence. The following table displays a constant date in the default format for each.

The first two lines of this table is a bit spurious, as no year "14" has never been seen in the wild - 1914 long pre-dated email and by 2014 4-digit years were well established, having been required by RFC-1123 since 1989.

RFC-822 described single-letter military timezones, but got the offsets wrong. The error was called out in RFC2822 4.3. The author has never seen these military timezone specifiers in the wild.

RFC-2822 deprecated named timezones more generally. RFC-5322 declared them obsolete.

All versions of email date stamps allow the day-of-week part (and its comma) to be omitted.

Look twice and check your data sources and your work when you are parsing things that look like email dates. It is regrettably common for programs generating timestamps intended to look like these to make small errors like omitting the comma, swapping the day and month parts, or even swapping the year and time-of-day parts. Some programs doing this sort of thing will even falsely claim to be shipping RFC822-conformant timestamps; Git is a notorious example.

Another source of such variation is appending a fractional-seconds part, as in "Fri, 24 Oct 2014 19:32:27.130 +0000". None of the email standards describe this. When there is a fractional-seconds part it is usually milliseconds, but that’s not a rule to be counted on.

Unix represents calendar time using the following structure, which is consumed or emitted by several key functions:

Many of the most common problems with using the Unix time API can be traced to the rather confused and inadequate design of this structure. In what is probably unintentional humor, various manual pages and standards documents refer to it as "broken-down time".

The most notable pain points include:

and, worst of all,

There is a potential overflow problem with tm_year on systems where sizeof(int) < sizeof(time_t); historically this was often true on 32-bit systems and may remain a hidden problem in embedded deployments. The year derived from a time_t can be so large that it won’t fit in an int, which means localtime(3) and gmtime(3) could silently fail on valid time stamps in the far past or far future. A subtler problem is that when tm_year > INT_MAX - 1900 the Gregorian year doesn’t fit in an int; a lot of code gets this wrong. Because INT_MAX on a 32-bit system is 2^31 = 2,147,483,647 this is unlikely to be a problem for normal historical dates.

Some versions of BSD remedied the last and most serious problem by adding two additional fields specifying the timezone used to generate the instance:

The GNU C library, used on most open-source Unixes, supports these members. The POSIX/SUS/OpenGroup standards allow them, but do not mandate them; in a strict ISO-C environment they will not be visible. You may have to #define _BSD_SOURCE before including time.h to make them visible.

The GNU C library documentation says this: "[The tm_gmtoff] field describes the time zone that was used to compute this broken-down time value, including any adjustment for daylight saving; it is the number of seconds that you must add to UTC to get local time. You can also think of this as the number of seconds east of UTC. For example, for U.S. Eastern Standard Time, the value is -5*60*60."

With the offset member (but not without it) a broken-down time specification is unambiguous.

The tm_zone member is less useful. The zone name strings it points to are not standardized and can be somewhat haphazard. They’re not the IANA geographic designators. Under Linux and BSD they’re typically the familiar (but ambiguous) three- and four-letter abbreviations (EDT, CEST, etc.), but under Windows they’re longer strings like "W. Europe Standard Time". (And they’re sometimes brain-bending monstrosities like "GMT Daylight Time", which is Microsoft’s own special name for what the Brits call British Summer Time.[MTZ])

The tzset(3) call computes the timezone offset for purposes of local-time computation. This information is expressed as three global variables (you may have to set feature macros to expose them).

These values are derived from system administrative settings and (if it is present) the value of the environment variable TZ, in ways too complex to delve into here; consult the manual pages for details. The key point is that after a tzset(3) call, the local timezone information should be available.

Note that the timezone offset does not include DST correction and is of opposite sign to the tm_gmtoff member.

The tzname variable is a pair of strings; tzname[0] is the zone name without and and tzname[1] is with DST correction. These will be civil zone names (like GMT/GST or EST/DST) not the IANA naming scheme.

tzset(3) is required by POSIX to be thread-safe, but access to the globals it sets is intrinsically thread-unsafe.

It should usually not be necessary to call tzset(3) directly, as it is called at the beginning of processing by most of the functions in this section. Exceptions will be noted below.

This part of the Unix time interface is very old; tzset(3) goes back to System III, and at least one of the globals it sets traces back to V6. Later portions of the Unix API design almost completely avoided predefined global variables in favor of returns from function calls.

Some early Unixes (including V7) had a a different way of fetching similar information; ftime(3). This call filled in a structure with members containing information similar to the exposed globals above:

The Single UNIX Specification carried this forward, but implementations were weak and defective. POSIX.1-2001/SUSv3 said that the contents of the timezone and dstflag fields are unspecified and should not be relied on. POSIX.1-2008/SUSv4 removed ftime(3) entirely. The archaic tzset(3) interface remains.

Final warning: some BSD Unixes do not implement timezone at all!

These are the basic functions for making a broken-down time structure struct tm from a time_t.

The difference between the gm* pair and the local* pair is this:

The local* pair computes the local time corresponding to the input Unix UTC time, taking the local time zone and all DST corrections into account. It does this by, in effect, adding the local timezone offset to the UTC seconds before performing the same computation performed by gmtime, although in a high-quality implementation it’s more complicated than that, because of the possibility that the addition could overflow.

The gm* pair applies no such offset, so the output struct tm expresses Unix UTC seconds as UTC time.

The names of the gm* pair are a historical error, since they actually convert to UTC. These systems are not actually identical; for real GMT we would incorporate the DST bit, but for UTC it must be ignored.

The functions gmtime(3) and localtime(3) return a pointer to internal static storage that is overwritten on each call (in the GNU C library this static storage is shared among both functions). This is not thread-safe. The *_r functions are, on the other hand, re-entrant, with the user being required to pass in the address of the storage to be modified, and can thus be thread-safe.

POSIX implies that localtime(3) is required to behave as though tzset(3) has been called, but that localtime_r(3) is not. This is almost certainly because tzset(3) sets globals; if localtime_r(3) also set them its callers could well become thread-unsafe.

For portable code tzset(3) should be called before localtime_r(3) - but note that this can lead to subtle errors when processing historical date/times because of the historical-date problem described under mktime(3).

Now that we’ve gone through the technical details, here is a less formal but more evocative way of summarizing them: localtime(3) is a pit of horrors that wants to be your personal hell - avoid. This is especially true if you are concerned about reproducibility (e.g. in unit and regression tests) where timezone- and DST-related problems can introduce random glitches like off-by-one-hour errors with no cause in your visible code.

The C11 standard [C11], in section 7.27.2.5, specifies a timespec_get(3) function that fills a struct timespec compatible with the POSIX definition, but is expected to be available on non-UNIX operating systems.

According to the standard, it "sets the interval pointed to by ts to hold the current calendar time based on the specified time base". Hoever, it also says that with a base of TIME_UTC, "the tv_sec member is set to the number of seconds since an implementation defined epoch". No base values other than TIME_UTC are specified in the standard, but impolementations ave the option to define others.

This language is more than a little confusing. The statement about TIME_UTC appears to imply interval time, a monotonic clock without skips or stutters due to leap second corrections as in the a call to clock_gettime(3) with mode CLOCK_REALTIME; on the other hand, "calendar time" implies an approximation to solar time with leap-second corrections.

It seems possible, even likely, that the behavior of this function is for base values other than TIME_UTC is expected to be different depending on whether the OS uses NTP to implicitly correct to true UTC time with leap-second correction. Use with caution and read your C library’s documentation to discover what might be specified about this.

The mktime(3) function inverts localtime(3), turning an input struct tm into a time_t. It is standardized.

There is no analogous standardized mkgmtime() function that inverts gmtime(3), but see the description of timegm(3) below.

The mktime(3) function has a side effect that can trip you up seriously if you’re not aware of it. In addition to returning a Unix seconds value, it also modifies the contents of the struct tm.

This means, in particular, that calling mktime(3) a second time on the same struct tm won’t necessarily return the same value as it did on the first call! The most likely error is for the second return to be 3600 seconds off because the first call set the tm_isdst member.

The manual page says:

"The mktime() function modifies the fields of the tm structure as follows: tm_wday and tm_yday are set to values determined from the contents of the other fields; if structure members are outside their valid interval, they will be normalized (so that, for example, 40 October is changed into 9 November); tm_isdst is set (regardless of its initial value) to a positive value or to 0, respectively, to indicate whether DST is or is not in effect at the specified time. Calling mktime() also sets the external variable tzname with information about the current timezone."

The last sentence is fairly subtle: it means that the implicit tzset(3) call at the beginning of mktime(3) can behave differently from an ordinary tzset(3) call, in that the implicit call can take advantage of knowing the time stamp that the caller is interested in, and can set global variables to values that are tailored for that time stamp. For example, if the time zone is Europe/London and the time stamp argument to mktime is circa 1970, mktime can set the global variables to values appropriate for a location that is at UTC+1 year round, which is what London was observing back in 1970; whereas if the time stamp is circa 2014, mktime can set the global variables to values appropriate for a location that is at UTC in winter and UTC+1 in summer, which is what London was doing in 2014.

The normalizing side-effect of mktime(3) makes it useful for various kinds of date/time arithmetic on broken-down time structures. For example, you can increment a tm_day member, call mktime(3) on it, and expect overflow beyond the end of month to be handled (but beware that this will be done without adjusting for leap-second discontinuities).

These are GNU C Library extensions, not standardized. They are modeled on calls introduced in BSD and still present in FreeBSD/NetBSD/OpenBSD.

The timelocal(3) function is identical to standard mktime(3) (except for assuming tm_isdst is initially negative, which mktime(3) does not) inverting localtime(3). The timegm(3) function inverts gmtime(3).

The GNU C Library documentation recommends against using these functions, as they introduce a dependency. It recommends this as a portable alternative (but note that it is thread-unsafe):

In older Unixes the following functions were available to report time and date as a string. They wired in bad design choices (the date string is of unpredictable length and includes a trailing "\n"), are not locale-aware, and have undefined behavior for years before 0 or after 9999.

These functions are obsolete and should not be used in production code; use strftime(3) instead. If you are curious about the details, read their manual pages.

This is the modern function for formatting timestamps into string representations; read its manual page. Here are some potentially interesting recipes that illustrate usage patterns:

RFC-822/RFC-2822 specifies English month and weekday names, but %a and %b are locale-aware; thus, the third recipe will deliver interestingly nonstandard results in a non-Anglophone locale.

Some of the format specifiers need to be used with caution; older implementations may not support all of them. Unit-test your formatting, checking carefully for %z and the other Single UNIX Specification and glibc additions (%C, %D, %E, %h, %n, %O, %P, %r, %t, %T, %V) if you must rely on them.

If called with a manually populated struct tm with all Standard C members populated, but without the tm_gmtoff and tm_zone members populated, strftime will, on some systems, not give sensible results for %z or %Z. Worse, it directly reads from the possibly-uninitialized tm_zone pointer.

More generally, %z and %Z for anything other than an immediate localtime(3)/strftime(3) pair can get wacky. In particular:

One unfortunate deficiency of strftime(3) is that it doesn’t have a format specifier for fractional seconds.

The strptime(3) function is a near-inverse of strftime(3) function, with one painful exception; it does not parse timezones. (If only because the misdesign of the standardized struct tm leaves it no place to put the information.) The full list of strftime(3) specifiers not supported are %F, %g, %G, %u, %v, %z, and %Z.

Do not use the %y specifier. Its interpretation differs incompatibly among implementations.

Test code that uses strptime(3) carefully on real data. Implementations are bug-prone.

Sadly, strptime(3) doesn’t have a specifier for fractional seconds.

The getdate(3) function and its re-entrant twin getdate_r(3) are complex and dubiously-designed attempts to do adaptive date parsing. We recommend against attempting to use them. See their manual pages for details.