Projects written in C often need timestamps for logs and pseudo random numbers for simulations or small games. The standard library covers these needs with a compact group of functions that work across platforms. Many implementations represent calendar time with a time_t value that often counts seconds from the Unix epoch, alongside a basic pseudo random number generator. That combination gives C code a portable way to record time, break it into calendar fields, and draw repeatable pseudo random values from a seeded sequence.
Time Handling In The C Standard Library
Time support in the C library revolves around a small group of related pieces. At the base there is a numeric count of seconds kept in time_t. That value can stay in that raw form for storage and comparison, or it can be fed into functions that fill a struct tm with calendar fields such as year and month, and then passed on to strftime to build readable strings. The same route can be followed in reverse when code starts from calendar fields and needs a numeric timestamp again.
Epoch Seconds With time_t
At the bottom of the time interface sits time_t, which holds a calendar time as a single arithmetic value. The standard leaves the exact representation open and only says that this type can hold time values supported by the implementation. Many Unix like systems treat time_t as a signed integer that counts whole seconds from the Unix epoch, defined as 00:00:00 UTC on 1 January 1970. Windows libraries track the same general era but may use different internal sizes or conversions behind time_t.
The function has this prototype:
This call returns the current calendar time as a time_t. When the argument pointer is not NULL, the current value is also written through that pointer. Failure is reported by returning (time_t)-1. That special result compares equal to (time_t)-1 but does not have to match any real timestamp.
This small utility prints the current raw value:
This main function calls time with a null pointer, checks for the error sentinel, and then prints the numeric result after casting to long. That cast appears in many teaching examples, although truly portable code treats time_t as its own type and avoids assumptions about long on every platform.
Comparisons between two timestamps can use the relational operators on time_t, but converting a gap into seconds is best done with difftime. difftime takes two time_t values and returns the difference in seconds as a double, which avoids depending on how an implementation represents time_t.
This example records two timestamps and asks difftime to express the gap in seconds with fractional precision. Internally, the library can pick whatever representation makes sense for time_t and still deliver a correct difference.
Many platforms moved from 32 bit to 64 bit time_t to allow dates well beyond the early 21st century. Code that stores time_t in smaller integer types can chop off higher bits and restrict the usable date range, so it is safer to keep this type in its native form and only cast for display.
Calendar Breakdowns With struct tm
Human facing time values need years, months, and days, not just a raw count of seconds. The C library stores that kind of view in struct tm, which lives in <time.h> and holds separate integer fields for date and time components along with weekday and year day information.
The standard layout looks like this in the header:
Several of these fields carry offsets rather than direct calendar numbers. Months count from zero, so January has tm_mon equal to 0 and December reaches 11. The tm_year field stores an offset from 1900, so a calendar year such as 2026 appears as tm_year equal to 126. Fields such as tm_wday and tm_yday give the day of week and the day number inside the year.
Conversion between time_t and struct tm usually goes through gmtime or localtime in one direction and mktime in the other. gmtime and localtime return pointers to internal static storage that can be overwritten by later calls, while mktime writes normalized fields back into the caller supplied struct tm and returns a time_t.
The function gmtime takes a pointer to a time_t value and fills a struct tm in Coordinated Universal Time. The pointer it returns points to an internal static object that can be reused on later calls. The related function localtime interprets the same time_t value through the active time zone and daylight saving rules, again returning a pointer to a static struct tm. Because that static storage can be overwritten by later conversions, code that needs to keep a struct tm result stable should copy it into its own variable.
The two calls to gmtime and localtime convert the same numeric timestamp into UTC and local calendar fields. Copying those results into utc_copy and loc_copy avoids surprises from later calls that would reuse the static storage.
Conversion from calendar fields back to a time_t runs through mktime. This function treats the input structure as a local time, normalizes fields that fall outside the normal ranges, fills in tm_wday and tm_yday, and returns the corresponding time_t value or (time_t)-1 when the resulting time falls outside the supported range.
The structure t starts out with a calendar date that does not exist. After mktime runs, the library adjusts month and day fields so that the structure represents a valid local time. Many platforms move such dates into March, but the exact result comes from the implementation and current time zone database.
Formatting With strftime
Text output for calendar data is usually built through strftime, which walks a struct tm and writes formatted characters into a caller supplied buffer. That function acts as the bridge from numeric fields to printable dates and times that can fit in logs, status messages, or user interfaces.
Its prototype looks like this:
Here, the s pointer refers to the buffer that receives the text, and max tells the function how many characters, including the terminating null character, are safe to write. The format string carries both literal characters and percent directives. Those directives pull values from the struct tm and convert them into text according to locale rules. A return value greater than zero reports the count of characters stored in the buffer, excluding the null terminator, while a return value of zero means the output did not fit, leaving the buffer contents unspecified.
Common directives include %Y for a four digit year, %m for a two digit month number from 01 through 12, %d for the day of month, %H for a 24 hour clock hour, %M for minutes, and %S for seconds. Many implementations also support %z for a numeric time zone offset and %Z for a time zone abbreviation, though those two are more dependent on platform and environment settings.
Let’s see a example that prints a local timestamp string:
![#include <stdio.h> #include <time.h> int main(void) { time_t now = time(NULL); if (now == (time_t)-1) { return 1; } struct tm *loc_tm = localtime(&now); if (!loc_tm) { return 1; } char buf[128]; size_t written = strftime(buf, sizeof buf, "%Y-%m-%d %H:%M:%S %Z", loc_tm); if (written == 0) { printf("Buffer too small for formatted time\n"); return 1; } printf("Local timestamp: %s\n", buf); return 0; }](https://substackcdn.com/image/fetch/$s_!vQvS!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ffb00180e-46a6-401d-8d76-623ee4fa20f5_1773x913.png "#include <stdio.h> #include <time.h> int main(void) { time_t now = time(NULL); if (now == (time_t)-1) { return 1; } struct tm *loc_tm = localtime(&now); if (!loc_tm) { return 1; } char buf[128]; size_t written = strftime(buf, sizeof buf, \"%Y-%m-%d %H:%M:%S %Z\", loc_tm); if (written == 0) { printf(\"Buffer too small for formatted time\n\"); return 1; } printf(\"Local timestamp: %s\n\", buf); return 0; }")
This main function takes the current time, converts it to a local struct tm, and asks strftime to produce a common year month day and time layout along with a time zone label. The return value from strftime makes it possible to check that the buffer was long enough.
Format strings can be adjusted to match many cultural expectations or strict technical layouts. A log file that wants UTC values can combine gmtime with strftime and a format that omits the time zone label entirely, while user facing output can rely on localtime and directives that abbreviate month and weekday names according to the active locale.
Pseudo Random Values In The C Standard Library
There are plenty of parts of C code that rely on pseudo random integers, whether for lightweight simulations, casual games, basic randomized testing, or small sampling routines. The standard library offers rand and srand for this purpose, backed by an implementation defined generator that returns integers in a fixed range and advances a shared internal state on each call. That design gives portable access to a repeatable sequence, but it comes with limits that matter once you start looking at ranges, seeding, and thread behavior.
How rand Generates Values
The rand function sits at the center of the standard pseudo random interface. It has a simple prototype in <stdlib.h>:
The related macro sets the upper bound for values returned from rand:
C standard requires RAND_MAX to be at least 32767, which fits in 15 bits. Many current libraries set it much higher, such as 2147483647 on systems where int is 32 bits wide, but portable code cannot rely on an exact value. What does stay fixed across platforms is that rand always produces an integer in the inclusive range from 0 to RAND_MAX.
The standard text does not lock in any particular algorithm for rand. Each implementation is free to choose a pseudo random generator that is deterministic based on some hidden state. The standard does not promise any particular distribution quality, so results vary across libraries. A common choice is a linear congruential generator, where each new state is a simple arithmetic function of the previous one, often involving a multiplication and an addition modulo some integer. That recurrence creates a sequence that repeats after a finite period, with the exact period and quality depending on constants chosen by the library.
Repeated calls to rand walk through that sequence. Each call produces a value that depends on the internal state, and the state then advances to prepare for the next call. If the state starts from the same seed, the sequence returns in the same order for that implementation. This determinism is useful for tests and reproducible data sets, but it also means an attacker with enough knowledge about the generator could predict future values, which is why rand is not suitable for cryptography or anything that relies on secrecy.
This main function prints a few rand results:
In that code, it calls rand several times in a row and prints the outputs. If you run this same binary twice without seeding, you can expect the sequence to repeat, because the internal state starts from the same default seed at process start on that implementation.
Applications rarely need the full 0 through RAND_MAX range directly. A more typical pattern uses rand as a source for values in a smaller band such as 0 to n - 1:
This helper maps the full range down to a smaller domain with the remainder operator. That mapping has a drawback whenever n does not divide RAND_MAX + 1 evenly, because some output values occur more frequently than others. The effect grows more noticeable as n approaches RAND_MAX + 1. For casual uses this may not matter, but statistical work that cares about uniformity generally prefers rejection sampling, where values above the largest multiple of n that fits in RAND_MAX + 1 are discarded and a fresh rand call is made for that position.
An adjusted version that avoids the skew looks like this:
This function computes a limit value so that every number from 0 up to but not including that limit can be mapped evenly onto 0 through n - 1. Any rand result above the limit is thrown away, and the loop tries again. That extra work trades some speed for a flatter distribution across the target range.
One more property that matters for many code bases is that rand usually holds its state in static storage that belongs to the C library. That detail makes it easy to share a generator across the entire process without passing a state object to each call, but it also means concurrent calls from multiple threads can collide. Unless the implementation documents extra guarantees, calls to rand from multiple threads at the same time may interleave in a way that triggers data races. Threaded applications that care about reproducibility or safety often move to thread local generators provided by other libraries instead of relying on the shared state behind rand.
Seeding With srand Plus Practical Limits
The other half of the interface, srand, sets the starting point for the rand sequence. Its prototype in <stdlib.h> is simple:
Calling srand with a particular seed value loads that number into the generator so that later calls to rand follow a specific path through the pseudo random sequence. When code calls srand with the same seed on the same implementation, the stream of results from rand will repeat in the same order, which is useful when tests need to replay a scenario or compare two builds.
Let’s see an example that seeds rand with a fixed value:
Anyone who compiles and runs this code on the same C library build can expect the same sequence of five integers each time, as long as the generator behind rand does not change.
Many small C applications want a different sequence on each run instead of a fixed one. Often small programs pick the seed from the current time, usually in seconds from time(NULL):
Here, this main function pulls the current calendar time, casts it down to an unsigned int, and passes that into srand. Runs started at different times will likely see different seeds and different sequences. There are still limits here, though. The resolution of time(NULL) is usually one second, so multiple processes that start within the same second can receive the same seed. On platforms where time_t is larger than unsigned int, the cast can also drop higher bits, which reduces the effective variety in seeds.
The C standard does not specify how long the pseudo random sequence is before it repeats. That length, called the period, depends on the algorithm and constants chosen by the implementation. Linear congruential generators can have long periods when tuned well, but they still repeat eventually and have structural patterns that show up under statistical tests. These properties are acceptable for classroom examples, small games that do not depend on secrecy, and basic randomized workloads, but they do not meet the needs of cryptographic randomness.
Modern environments usually provide stronger random sources that sit outside the C standard library. Common examples include getrandom on Linux, arc4random on BSD family systems, and cryptographic libraries that wrap operating system random devices. Those interfaces provide higher quality randomness suitable for session identifiers, encryption keys, and other security critical values, while rand and srand stay focused on legacy compatibility and simple pseudo random sequences inside the C standard.
Conclusion
Time and randomness in the C standard library come down to a small set of related pieces. On the time side, time_t, struct tm, and strftime turn a raw time_t value into calendar fields and formatted strings that fit logs and user facing output. On the pseudo random side, rand and srand deliver a deterministic sequence of integers driven by a seed, which works well for teaching, lightweight simulations, and situations where repeatable behavior matters more than secrecy. Keeping these mechanics in mind makes it easier to decide when the standard interfaces are enough on their own and when a project should reach for higher resolution clocks or stronger random sources supplied by the operating system or external libraries.