New Zealander here, really thrilled to see our national medical testing service (primarily blood tests) in here. I've sent a note to them to make sure they're aware of this.
Also I feel like I took the wrong path, trying to be a serious and responsible software developer - seems like all the money is in throwing shit together and making wild claims about it.
For events that have happened, absolutely. Events in the future are often slightly more ambiguous though!
I do agree that "with attached Timezone" or "as UTC" are absolutely the sensible defaults, I'm just suggesting that sometimes "plain" datetimes are semantically the correct choice.
For sure, but for future events to be correct I still have to store that as (plain datetime, pacific/auckland), not translated to utc at the point of creation/saving. If I store only a UTC datetime I have unrecoverable lost important information.
Calendar events often want to be interpreted according to whatever the local timezone currently is. For instance "10am every second Sunday" shouldn't adjust to 9am during Daylight-Savings time. And my 7am alarm clock should definitely not change to 7pm because I flew from Aotearoa to England.
I'm sure it's been discussed here before, but for calendar events you don't necessarily want a timezone attached, you want a location - "this event happens at 9am according to whatever timezone is currently in effect in Auckland, NZ". That's a thing that UTC or timezone-aware Datetimes can't help with.
I'm a some-time Django developer and... I caught the bug instantly. Once I saw it was model/ORM code it was the first thing I looked for.
I say that not to brag because (a) default args is a known python footgun area already and (b) I'd hope most developers with any real Django or SQLAlchemy experience would have caught this pretty quick. I guess I'm just suggesting that maybe domain experience is actually worth something?
Natron is essentially a clone of Nuke, the ~standard compositing software for the VFX industry. It's impressive that it exists and competes with some very expensive alternatives.
Its maths and colour science is good and it seems to operate correctly on images. Unfortunately usability and performance are pretty weak. I've managed to replace Nuke or Resolve with it for the parts of my workflow that are colour conversions from e.g. ACEScg to sRGB, or for encoding videos (it wraps ffmpeg), but I'd hesitate to use it for anything creative and it definitely doesn't approach the animation facilities of After Effects.
I use Podman on both macos and Windows, with compose files, so I'm a bit perplexed by this whole comment.