tzset(3)

💖 tzset(3) — okay bestie, let's talk TIME ZONES 💖

No cap, this is the page for tzset, tzname, timezone, and daylight — the whole little squad that initializes your time conversion info. It lives in the Library Functions Manual, and girlypop, it is exactly as chaotic as time zones themselves. ✨

---

🌸 LIBRARY 🌸

Standard C library (libc, -lc) 🫶

---

✨ SYNOPSIS ✨

#include <time.h>

void tzset(void);

extern char *tzname[2];
extern long timezone;
extern int daylight;

🎀 Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

tzset():
    _POSIX_C_SOURCE

tzname:
    _POSIX_C_SOURCE

timezone, daylight:
    _XOPEN_SOURCE
        || /* glibc >= 2.19: */ _DEFAULT_SOURCE
        || /* glibc <= 2.19: */ _SVID_SOURCE

Like, do NOT forget the macros or the compiler will simply not let you have your little functions. 💅

---

🦋 DESCRIPTION 🦋

Okay so the way that tzset() works is: it initializes the tzname variable from the TZ environment variable. And here's the cute part — you don't even have to call it, because the other time conversion functions that depend on the timezone call it for you automatically. Not me being needy at all, it's just handled. 😌

In a System-V-like environment it will also set these variables:

• timezone — seconds West of UTC (yes, West, we'll get to that)
• daylight — set to 0 if this timezone has no daylight saving time rules, or nonzero if there is a time, past, present, or future when daylight saving time applies

Heads up bestie: tzset() initializes those three variables to unspecified values if the timezone is a geographical timezone like "America/New_York" (more on that below). So don't go trusting them, okay? 🚩

🧚 Where does the timezone even come from

If the TZ variable is not in the environment, the system timezone is used. And how does the system get its timezone? By copying, or linking, a file in the tzfile(5) format to /etc/localtime. A whole database of these files may live in the system timezone directory (peep the FILES section further down 💖).

If TZ does appear in the environment, but its value is empty, or its value can't be interpreted using any of the formats down below, then Coordinated Universal Time (UTC) is used. Simple as that.

🌈 The two formats (this is the main character section)

A nonempty value of TZ can be one of two formats — and either one can be preceded by a colon, which is just ignored. Rude, but fine. 🙈

Format 1: the inline string 💅

The first format is a string of characters that directly represent the timezone to be used:

std offset[dst[offset][,start[/time],end[/time]]]

There are no spaces in the specification. Groundbreaking. Here's the breakdown:

• The std string specifies an abbreviation for the timezone and must be three or more alphabetic characters. When you enclose it between the less-than (<) and greater-than (>) signs, the character set is expanded to include the plus (+) sign, the minus (-) sign, and digits.
• The offset string immediately follows std and specifies the time value to be added to the local time to get Coordinated Universal Time (UTC). The offset is positive if the local timezone is west of the Prime Meridian and negative if it is east. (Yes, it's backwards from what your brain wants. It's giving "we did this on purpose." 😭)
• The hour must be between 0 and 24, and the minutes and seconds 00 and 59:

[+|-]hh[:mm[:ss]]

• The dst string and offset specify the name and offset for the corresponding daylight saving timezone. If the offset is omitted, it defaults to one hour ahead of standard time.

The start field says when daylight saving time goes into effect, and the end field says when the change is made back to standard time. These fields may have the following formats:

• Jn — This specifies the Julian day with n between 1 and 365. Leap days are not counted. In this format, February 29 can't be represented; February 28 is day 59, and March 1 is always day 60. 💀
• n — This specifies the zero-based Julian day with n between 0 and 365. February 29 is counted in leap years. Slay, inclusivity.
• Mm.w.d — This specifies day d (0 <= d <= 6) of week w (1 <= w <= 5) of month m (1 <= m <= 12). Week 1 is the first week in which day d occurs and week 5 is the last week in which day d occurs. Day 0 is a Sunday.

The time fields specify when, in the local time currently in effect, the change to the other time occurs. They use the same format as offset, except that the hour can be in the range [-167, 167] to represent times before and after the named day. If omitted, the default is 02:00:00. 👑

Here's an example for New Zealand, where the standard time (NZST) is 12 hours ahead of UTC, and daylight saving time (NZDT), 13 hours ahead of UTC, runs from September's last Sunday, at the default time 02:00:00, to April's first Sunday at 03:00:00:

TZ="NZST-12:00:00NZDT-13:00:00,M9.5.0,M4.1.0/3"

Ate. ✨

Format 2: the geographical format 🗺️

The second — or "geographical" — format specifies that the timezone information should be read from a file:

filespec

The filespec specifies a tzfile(5)-format file to read the timezone information from. If filespec does not begin with a /, the file specification is relative to the system timezone directory.

If the specified file cannot be read or interpreted, Coordinated Universal Time (UTC) is used — however, applications should not depend on random filespec values standing for UTC, as TZ formats may be extended in the future. So no relying on the fallback, bestie, that's undefined-behavior-adjacent energy. 🚫

Here's an example, once more for New Zealand:

TZ="Pacific/Auckland"

---

🌍 ENVIRONMENT 🌍

• TZ — If this variable is set, its value takes precedence over the system configured timezone.
• TZDIR — If this variable is set, its value takes precedence over the system configured timezone database directory path.

---

🍓 FILES 🍓

• /etc/localtime — The system timezone file.
• /usr/share/zoneinfo/ — The system timezone database directory.
• /usr/share/zoneinfo/posixrules — When a TZ string includes a dst timezone without anything following it, then this file is used for the start/end rules. It is in the tzfile(5) format. By default, the zoneinfo Makefile hard links it to the America/New_York tzfile.

Above are the current standard file locations, but they are configurable when glibc is compiled. So like, your distro might've done something else. iykyk. 🙃

---

💜 ATTRIBUTES 💜

For an explanation of the terms used in this section, see attributes(7).

• tzset() — Thread safety: MT-Safe env locale

(Original page had this in a cute little table, but we're keeping it as a bullet, mwah.)

---

⭐ STANDARDS ⭐

POSIX.1-2024. 💅

---

🌸 HISTORY 🌸

• tzset(), tzname — POSIX.1-1988, SVr4, 4.3BSD.
• timezone, daylight — POSIX.1-2001 (XSI), SVr4, 4.3BSD.

And here's some lore for you: 4.3BSD had a function

char *timezone(zone, dst)

that returned the name of the timezone corresponding to its first argument (minutes West of UTC). If the second argument was 0, the standard name was used, otherwise the daylight saving time version. Vintage icon behavior. 👑

---

🚨 CAVEATS 🚨

Because the values of tzname, timezone, and daylight are often unspecified, and accessing them can lead to undefined behavior in multithreaded applications, code should instead obtain the time zone offset and abbreviations from the tm_gmtoff and tm_zone members of the broken-down time structure tm(3type).

Do not touch those globals in a threaded program. It's giving "I like to live dangerously" and we are NOT doing that today. Use tm_gmtoff and tm_zone. Periodt. 💅

---

💀 BUGS 💀

Since this function does not report errors, there's no way to know if the value of TZ represents a valid time zone. That's it. That's the bug. It just shrugs at you. 😭

---

🫶 SEE ALSO 🫶

date(1), gettimeofday(2), time(2), ctime(3), getenv(3), tzfile(5)

---

okay and that's the whole page, bestie, you're officially a time zone girlie now 💖✨🦋

This one's from Linux man-pages 6.20, dated 2026-02-08. Go forth and TZ responsibly. 🌈👑