this post was submitted on 29 Dec 2025
9 points (90.9% liked)
Golang
2599 readers
18 users here now
This is a community dedicated to the go programming language.
Useful Links:
Rules:
- Posts must be relevant to Go
- No NSFW content
- No hate speech, bigotry, etc
- Try to keep discussions on topic
- No spam of tools/companies/advertisements
- It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
TL;DR; Some bit of Go (or at least a Go lib they're using) coerces NULL time values to 0, so they added logic later down the data pipeline to check for 0s and convert them back to NULLs.
The full context of the problem definitely sounds tricky, like I doubt I would have realized it during development, but that little bit of data coersion logic is a HUGE code smell, for me. Never would have passed review, in my book.
The author's takeaway seems to be "just cause you've fixed a bug doesn't mean that's the end of the story," which is valid, but the far more important takeaway for me is "don't compromise on best practices in data management." Like, in this case, they had a data model that leverages NULL (to indicate a "don't overwrite this field" scenario, and they fed it into something that doesn't support NULLs. They KNEW about this, and papered over it with a lossy data conversion, instead of actually implementing proper NULL handling for this conversion, or changing the data model to not require use of NULLs.
I don't do Go (thankfully). But that description reminded me of "A False Midnight", which is a Python story from almost 12 years ago (time flies).
The fact that these two stories concern Python and Go, the two supposedly easy and simple languages, are good examples of why such descriptors were always intellectual smell.
Makes me wonder what were legitimate uses
datetimeauthors mentioned existed forif time:meaningif time is not None and also not a midnight in UTC. I would kinda understand for non UTC, and maybe there are uses for date libraries' internals, but other than thet it seems too arbitraryThe core bug was that they were reading from a map without checking if the map entry existed. Given a non-nil
var m map[K]V,m[key]always succeeds (never panics). If the given entry doesn’t exist, it returns the zero value for the type, i.e.var v V. If V is a pointer type, accessing a field or method will panic (because the zero value is nil). If V is a struct or other value type, it can be used normally. That bug is on them. Any Go developer who isn’t a novice should know how maps and value types behave.They also didn't use adequate guardrails to validate data.