24 lines
1.5 KiB
Markdown
24 lines
1.5 KiB
Markdown
---
|
|
layout: post
|
|
title: The Trouble with Time
|
|
date: 2022-03-01
|
|
---
|
|
|
|
We are all bound by an oppressive force. One which declares what we must say and when we must say it. I am, of course,
|
|
referring to tzdata.
|
|
|
|
The Time Zone Database, or tzdata, is a list of time zones. Each entry includes information about UTC offsets, when
|
|
daylight savings time begins and ends, and historical information about time changes. For example, if you ask tzdata about the zone
|
|
`America/New_York`, referring to New York City, NY, USA, it will tell you that NYC was 4 hours, 56 minutes, and 2 seconds behind Greenwich
|
|
until 18 November 1883, when it switched to 5 hours behind. It can also tell you when DST started and ended every year from 1920, when NYC
|
|
introduced it, until now (and can predict when it may happen again in future years.
|
|
|
|
If you're scheduling an event or even just showing a clock this information is essential. tzdata gives you this information
|
|
for the entire world, with frequent updates when countries change their time zones and DST rules. That's why tzdata is used
|
|
by billions of computers worldwide.
|
|
|
|
Unfortunately, dealing with time is quite complicated. tzdata asserts that a time zone is an area where the time rules have been uniform
|
|
since 1970. That zone will then be named by the largest city within the area.
|
|
Continuing our NYC example, Washington DC's time has never differed from NYC since 1970 and it is smaller than NYC,
|
|
so there's no `America/Washington_DC` and residents of DC will just use `America/New_York`
|