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.
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.
> That's a thing that UTC or timezone-aware Datetimes can't help with.
Modern datetime systems (including Temporal) use identifiers rather than offsets, which are almost as good as a location as long as governments don't redraw the boundaries. And Auckland is in fact the canonical city for the main New Zealand timezone, so specifying your timezone as "Pacific/Auckland" will get you pretty much the thing you want. In Temporal, this would be e.g.
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.
Even in your example those events do happen at a certain point in time. And if some attendees are virtual they may be several zones away. Ultimately people want to see their local TZ, whilst they want unambiguous data backing it.
Alarms are something of a special case, and with TZ aware types one could still adapt at the application later.
For a gift card system I once had relative expiration, enforced using the zone of the merchant location. Using a relative type actually felt like more work because from the merchant perspective, all that mattered was the point in time relative to their zone. It would've been simpler to do the offsetting in the app layer checks. And ultimately no one cared enough to keep maintaining it anyway, having an absolute point in time is usually good enough or even preferred.
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.
I get that of course, but on the other hand I'm sure you know what I'm getting at too: users of certain languages, platforms etc feel the need to announce it as a point of pride, or feature in itself, and frequently. Every language will have this to some degree (with the possible exception of COBOL, lol), but there are definite outliers.
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?
I've since moved on to primarily working with Java, so it's been a few years since working with Django on a daily basis and the default still jumped out to me immediately. Experience and domain knowledge is so important, especially when you need to evaluate ChatGPT's code for quality and correctness.
Also, where were their tests in the first place? Or am I expecting too much there?
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've only played with Nim a little, but I found it really compelling and honestly quite fun to write. It's quite elegant and economical and the performance is impressive for the lack of ceremony.
However, the language itself still seems to be a little in flux (v2.0 is nearly out, and my impression is that v3.0 might finally be a nice stable language) and the BDFL makes some language decisions (and holds some opinions) that I'm not fully on board with, and I think make the language a little less than it could be. Obviously that's subjective though.
I'll definitely keep an eye on it and check back in periodically, but I'm also not going to write any non-disposable code in it for now.
`grep -w 'pointer|ptr|addr|cast'` would do it in one.. (One can surely do a shell alias called `find-unsafe`..).
Finding unsafe constructs in Nim code is not that hard, at least at the same level of accuracy as `grep unsafe *.rs` (e.g. inside comments & strings, etc.).
To evaluate the power of this general line of argument, consider -- if Nim shipped with a `find-unsafe` source-level search utility, how much would this change your mind?
NZ isn't currently issuing visas outside of a few categories of "special worker in shortage". (In order to citizens and residents a better chance at getting a quarantine spot.) So this introduces a new special exception for the very wealthy.
In the biggest economic slump since the Great Depression maybe it makes sense to consider rich people who invest lots of money into the economy a "specialized worker" since they might play an important role helping recovery.
And that's fair enough but if there are limited spots they should go to existing NZ citizens/residents, and those with the greatest m=need should be prioritised.
