HN user

dan_sbl

133 karma
Posts4
Comments23
View on HN

`timestamptz` is probably poorly named. It doesn't actually store a timezone at all - all values are stored as UTC. The underlying storage is 8 bytes and otherwise identical for both timestamp types. However, using `timestamptz` allows you to more easily group by day, hour of day, etc. in a non-UTC timezone when that makes sense. Especially when dealing with summer time/daylight savings time, this can be quite useful.

As far as storing a datetime with an associated timezone, I agree that usually this can be problematic. However, for things like weekly repeats, you may want to store broken out components so it handles cleanly across time switch boundaries - e.g. when going in and out of DST. So you'd have `timezone`, `time` (no TZ, no date), repeat schedule (likely using interval, internally stored in months/days/microseconds), and use these to set up your next exact timestamptz value.

GTFS is widely adopted, "standardized", but also quite a wild west when it comes to the actual details. I've been building http://mobility-bot.com/ as a spare time project for two years, parsing the alerts GTFS feeds from a handful of providers, and for just about every one of them, I have to do something in the pipeline to clean up the provided data - fixing unicode issues, remapping route and agency IDs, rewriting headers and descriptions to not be identical, etc. You also have to watch and capture the data over time to make sure you have a corpus to generalize parsing and cleanup rules from.

Most of these projects made the smart choice to focus on a single or just a small handful of related providers. As soon as you're trying to aggregate, the problem becomes a lot trickier.

Workers Cache 16 days ago

Billion dollar company can't afford one human copywriter. The future is great! (edit: copyrighter -> copywriter)

The test suites run in public CI.

Each card links to the CI pipeline.

Thanks for being explicit, AI written marketing site. Wouldn't have been able to figure that out! Every currently maintained and reasonably popular open source project either runs CI in public or makes the tests extremely easy to run.

unveiling it to the confusion of officials and competitors in a 150 yard medley race in 1933

The article doesn't say, but did the medley relay/IM become a 4 stroke event around the same time in 1952 when FINA recognized it as a new stroke? Funny to see a 150 yard event mentioned since it seems like such an odd distance nowadays.

This feels like what is really splitting the programming community right now- those that have typically enjoyed the journey, and those that just want to be at the destination as soon as possible.

As a side effect, Terms-of-service acceptance records were also reset, prompting users to re-accept on their next visit to the dashboard.

Don't get me wrong- the rest of this mess falls pretty clearly on Google Cloud, but this one feels like something Railway did to themselves.

I wrote up our experience of how to get Tiptap to play nice with a Go backend server, along with a lot of inline code snippets and a gist with the backend code. Happy to answer any other questions I may have missed in writing it up.

Even if you don't use the Tiptap editor, hopefully the idea of a sidecar container is helpful to someone trying to solve a similar problem of allowing Typescript/Node code to interact with Go.

Good luck, and I hope it works out! Make sure you are ready to ride the roller coaster of highs and lows, as there are going to be many. Remember that your time and experience are the most valuable things you have - make sure you're in control of both.

As mentioned before, the CI critical path is bound by its longest stretch of dependent actions. If one test consistently takes 20 minutes to execute and flakes, and has some logic to retry on failure, let’s say up to 3 times, it’ll take up to 60 minutes. It doesn’t matter if all other builds and tests execute in 30 seconds. That one slow, flaky test holds everyone’s builds back for up to 1 hour.

Honestly, really surprised to not see this mentioned til the end. Some of the other things in the article were almost jaw-dropping ($1+ million in instances savings, needing 48 cores to run CI, etc.), but having flakey tests regularly causing you problems, having to rerun extremely expensive jobs, is something that I would argue should have been addressed first, not last.

Like some other commenters here who started with Bootstrap/jQuery/etc., I feel stuck in the stone ages at times. My most recent content-based site uses Hugo (https://gohugo.io/), but I'm starting to tire of the magic and gotchas I keep running into.

Can someone that has used Astro and an older static site generator framework explain the pros/cons of Astro in that context?