Timezones as Types: Making Time Safer to Use in Go
Posted3 months agoActive2 months ago
matthewhalpern.comTechstory
calmpositive
Debate
10/100
Go ProgrammingType SafetyTimezones
Key topics
Go Programming
Type Safety
Timezones
The article discusses a technique for making timezones safer to use in Go by utilizing the type system, and the discussion revolves around the trade-offs and potential applications of this approach.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
38m
Peak period
1
0-1h
Avg / period
1
Key moments
- 01Story posted
Oct 19, 2025 at 12:35 PM EDT
3 months ago
Step 01 - 02First comment
Oct 19, 2025 at 1:13 PM EDT
38m after posting
Step 02 - 03Peak activity
1 comments in 0-1h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 20, 2025 at 12:31 AM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45635553Type: storyLast synced: 11/17/2025, 9:05:26 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Depending on the time of year, Eastern Time will either match "Eastern Standard Time" or "Eastern Daylight Time". Forcing the time to always be "Eastern Standard Time" means that the times will be offset by an hour from the user's expectation about half of the year.
Arizona Exception: if you're in the boundaries of Arizona, you might need to correctly specify whether you mean a "Standard" time or a time which switches based on Daylight Savings. Different places in the boundaries of Arizona work differently.
> the variables est and estTime are both mis-named. The correct name for "the time in New York" is Eastern Time.
Yes, that is a good catch. The variables were mis-named and should have been "eastern" (ET) and "pacific" (PT) and not EST/PST given that "America/New_York" and America/Los_Angeles" were the reference timezone. If someone just wants EST or PST they would need to create a timezone bound to just that. The library supports statically typing either and would prevent EST/ET or PST/PT from being used interchangeably.
> Depending on the time of year, Eastern Time will either match "Eastern Standard Time" or "Eastern Daylight Time". Forcing the time to always be "Eastern Standard Time" means that the times will be offset by an hour from the user's expectation about half of the year.
Yes, agreed. The original naming was not correct and has been fixed.
> Arizona Exception: if you're in the boundaries of Arizona, you might need to correctly specify whether you mean a "Standard" time or a time which switches based on Daylight Savings. Different places in the boundaries of Arizona work differently.
he library should be able to support this behavior, but it would be important for the caller to know what timezone they should be using: (i) Navajo nation would use a timezone bound to "America/Denver and (ii) everywhere else inside would use "America/Phoenix". [1]
> Among other problems
I appreciate you raising the points above! I hope you can see I am open to feedback and take improving this work seriously. If you are wouldn't mind sharing the rest of what you are seeing, I would be interested in hearing more.
[1] https://en.wikipedia.org/wiki/Time_in_Arizona