Show HN: Semantic Calculator (king-man+woman=?) (calc.datova.ai)
50 points by nxa 2h ago 58 comments
Launch HN: Jazzberry (YC X25) – AI agent for finding bugs
26 points by MarcoDewey 6h ago 17 comments
UTC is Enough for Everyone, Right? (2018)
11 Tomte 5 5/14/2025, 6:50:18 PM zachholman.com ↗
Which is fine, in a way -- it won't store the wrong instant in time. But it also won't let you know the time the user sees. For example, you might want to tell someone when the store opens.
Fine, you say. You can look up the location of the store and use that to get the timezone. But what about a different case? What about if you want a user to test their blood sugar every day. Did they test their blood sugar on Tuesday? Well, then it depends what timezone they're in. What is the problem with having each user set their time zone? Isn't this just like the store issue?
No! Notably, unlike stores located in fixed buildings, people move around. They go on vacation. And if you don't know where they were when an event happened, you don't know what time the user was.
So it seems you have to, when you get a timestamp with time zone from a user, store the timestamptz, but also store the time zone in the database.
How frustrating, for a database that has a data type called "timestamp with time zone".
> Sometimes we’d be working on something that tangentially related to time, and as kind of a recurring in-joke he’d always tell me: Zach, whatever you do: just don't ever build a calendar.
> Anyway, I’m Zach Holman and I’m [building a calendar](https://during.com).
> During is no longer a thing.
Good on them for trying.
Your approach is usually going to be sufficient-ish for timestamping past events - which is most applications. But try to build a calendar, and you'll quickly notice that it simply doesn't work that way.