iana-time-zone

Get the IANA time zone name for the current system, on every platform Rust runs on.

Library
Cargo
v0.1.65
51stars
MIT OR Apache-2.0

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
33/100Needs Attention
Development Activity12
Maintenance0
Community48
Maturity60
Momentum12

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
83/100Excellent
Architecture85
Code Quality80
Innovation88
Learning Curve92

iana-time-zone is a small, focused Rust crate that answers a single deceptively hard question: what IANA time zone (such as America/New_York or Europe/Berlin) is the current system configured for? It abstracts away the wildly different mechanisms each operating system uses to store that information behind one tiny, dependency-light API.

It underpins much of the Rust date-and-time ecosystem, including chrono, and supports an unusually broad set of targets: Linux, macOS and other Apple platforms, Windows, the BSDs, illumos, Haiku, AIX, Android, and several WebAssembly flavors. The result is that higher-level libraries can offer correct local-time handling without each reinventing platform-specific detection.

What You Get

  • A single get_timezone() entry point returning the IANA zone name as a String
  • Correct detection across Linux, Apple platforms, Windows, BSDs, illumos, Haiku, AIX, Android, and WebAssembly
  • A minimal dependency footprint with platform-specific deps pulled in only where needed
  • An optional fallback feature so builds succeed on unknown targets and surface an error at runtime
  • Dual MIT / Apache-2.0 licensing suitable for virtually any project

Common Use Cases

  • Powering local-time conversions in date/time libraries such as chrono
  • Displaying timestamps in the user’s own time zone in CLI and desktop apps
  • Logging and telemetry that need the host’s canonical zone name
  • Cross-platform applications that must behave identically on Linux, macOS, and Windows

Under The Hood

Architecture — The crate’s public surface in src/lib.rs is a thin dispatcher over a set of platform modules (tz_linux.rs, tz_darwin.rs, tz_windows.rs, tz_freebsd.rs, tz_illumos.rs, tz_haiku.rs, tz_aix.rs, tz_android.rs, and several tz_wasm32_* variants), each selected by cfg attributes so exactly one implementation compiles per target. Detection strategies differ per platform: reading /etc/localtime symlinks on Linux/BSD, Core Foundation on Apple, Win32 APIs on Windows, and JS interop on wasm.

Tech Stack — Pure Rust (edition 2021, MSRV 1.62), with platform-gated dependencies such as core-foundation-sys, windows-core, android_system_properties, and js-sys/wasm-bindgen for the WebAssembly targets. There are effectively no dependencies on common platforms like Linux.

Code Quality — The codebase is small and well-scoped, with per-platform tests (for example in tz_linux.rs and ffi_utils.rs), example programs under examples/, and a maintained CHANGELOG. FFI helpers are isolated in ffi_utils.rs to keep unsafe code contained.

API Design — Extremely ergonomic: a single get_timezone() call returning a Result<String, GetTimezoneError>. There is essentially nothing to learn beyond that one function, and the error type is small and self-explanatory.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search