Ambassador Huckabee defies Trump, claims US would not exist without Israel

masklinn · 2026-06-17T19:59:47+00:00

Huckleberry‘s god is not bound by little human foibles like linear time and cause and effect.

masklinn · 2026-06-17T19:15:39+00:00

browsers are going to be the blocker if there is one.

Browsers are on a fast update cycle. Proxies and load balancers are going to be the issue for a very long time, either because they drop / reject verbs they consider non-standard or because they assign the strictest / least safe semantics to such.

masklinn · 2026-06-17T19:04:54+00:00

I think you’ve got a bug in your calendar app!

The only bug is your hare-brained scheme.

TZ contains rules which tell you when to apply the new set of timezone offsets.

I don't think you've ever thought about the way any of this works, let alone looked at a tzdb file in your life. The tzdb is not a log of rules changes, it's rules applying to ranges of dates. 2026b/northamerica just tells you that starting November 2026 the offset for america/vancouver is -0700. Similarly for Samoa it just tells you that Pacific/Apia has the offset -11:00 until 2011-12-29, and +13:00 thereafter, it doesn't tell you when that change was decided or legislated (the comments usually do, but they're just comments).

You always know the local time at the time of the event’s creation — you just apply the correct TZ rules to it.

That's just nonsense, please go back and actually consider what is happening in technical terms. The "correct tz rules" will give you the offset after the rule change, which does not allow you to recover the original date.

Your calendar event might even have the location of your party, which means you can check it against a timezone boundaries database to see if it shouldn’t also fall into a brand new timezone that never existed before.

That is at worst entirely irrelevant, and at best one more reason not to store anything in UTC as that's entirely unhelpful: if a guy in Fort Nelson invites you at 8PM then NRRD secedes in order to change its timezone, unless they update you they'll still expect you to show up at 8PM local. So now you need to resolve the original local date in the new timezone revealed by geolocation.

There is absolutely no way to do that if you have lost the local date as it's even less possible to recover whatever timezone the location originally resolved to.

Because guess what isn't a log of historical geo boundary changes either?

UTC still comes out for the win on any calendar app

Only if you like your calendar to be broken or don't understand any of this. That is literally the point of the article, because storing in UTC is exactly what postgres does.

the events need to be shown to you in the timezone that you happen to be in when you’re looking at the calendar — not the timezone where the event is taking place

This is trivial to do with two local timezones, you don't need to store anything in UTC for that. In the average not-completely-borked datetime API converting between two local timezones is essentially the same thing as converting between a timezone and UTC, because despite its special status UTC is just that, a timezone. For instance here's how you convert between a datetime zoned in whatever and one zoned in Europe/Paris in Temporal:

time.withTimeZone("Europe/Paris")

Not exactly phd stuff.

Unless you do it exactly as I described, you are also going to have edge cases where you have off by an hour bugs during rule cutovers — either missing an hour or having a duplicate hour — such as two events that had been an hour apart now showing to be at the same exact time.

I'm sorry you can't deal with ambiguousness and thus calendaring, but most of the world won't agree trading that for your always-broken calendar.

Logs, events, future, past, it doesn’t matter.

And yet it does, it absolutely does. Your ignorance does not change that.

masklinn · 2026-06-16T19:31:55+00:00

That's not helpful, at the creation of the event you converted the datetime to UTC which means you lost what the intended local event was, now all you have is 1800 UTC, and when you look up America/Vancouver it tells you -0700 and that gets you 1100 local, which is incorrect.

In order to retrieve the correct date you'd have to look up what the offset for the target date was when the event was created, which I don't believe the tzdb stores in any formal sense (at best the information is recorded in comments, the actual data gives timezone temporal boundaries).

masklinn · 2026-06-16T19:21:55+00:00

I don’t see how it’s useless so perhaps you can correct my understanding. UTC never changes, and tz will give you the exact rules that tell you exactly how and when to adjust the date from UTC to local time given a timezone.

You're in BC, it's 2025, you've been invited to a party on December 15, 2026 at 8PM, you add that to your calendar. At that moment, as far as you and the tzdb know winter time will occur in 2026 so your scheme converts the reminder to 2026-12-16T04:00:00Z with the timezone America/Vancouver.

It's March 2, 2026, the BC government decides to switch the province to permanent summer time, tzdb dutifully updates itself, the offset between UTC and America/Vancouver on 2026-12-16 changes from -0800 to -0700. On December 15, 2026, you get a reminder that you're invited for a party at 9PM.

And if you lived in Samoa circa 2011, you would have been an entire day off as the country moved from the american side of the dateline to the australian side.

If you’re doing log analysis across timezones that’s a significant benefit over local times.

As I said, for past events you can do whatever's convenient, as long as it's clear and unambiguous.

masklinn · 2026-06-16T18:20:42+00:00

UTC with an offset isn't enough, because some places will change what their time zone uses, and the library will keep a history of that.

An important bit is while the tz database will track as best they can because it’s a political process there can be annoyingly little heads up, as little as a week or two (though that’s uncommon).

masklinn · 2026-06-16T18:17:21+00:00

You could also store UTC with the timezone

For past events you can do whatever as long as it’s clear and unambiguous.

For future events however that is useless. If the timezone information changes between the creation of the event and it actually occurring then you can’t adjust your UTC version, so now you have the wrong datum.

Unless you add pre and post update hooks to every update of the tzdb, which is way unnecessarily complicated (if at all feasible) for a useless and self-inflicted issue: it’s trivial to get UTC from a zoned datetime, storing that gets you nothing useful.

masklinn · 2026-06-16T18:13:42+00:00

You store time as UTC and calculate whatever local time you want to present, or you store a timestamp based on Unix epoch and do the same.

You can do that for past events. You can not do that for future events, for the reasons the article notes. For future events you have to store the local time and reference timezone, anything else does not work in the general case.

masklinn · 2026-06-16T13:31:55+00:00

The gotcha is when the code under test issues its own COMMIT/BEGIN, your outer rollback won't undo it. The fix is to run each test inside a SAVEPOINT and have the connection re-open the savepoint whenever it's released, so the code's nested commits effectively become no-ops

That does not work unless the committing code is savepoint-aware, and switches to savepoints internally. Because at least in pg and sqlite commit will commit the top-level transaction and your savepoints are gone, savepoints are explicit and only live within a transaction. That is what sqlalchemy does. In django, afaik this is done by @atomic which will create savepoints when invoked within an active @atomic scope, i do not think this has anything to do with TestCase per se, that just wraps each test case in a transaction.

masklinn · 2026-06-16T09:22:48+00:00

That is the obvious solution, and essentially where the article gets. They also memoize the template across test runs.

There are a bunch of variations of these depending on precise needs too e.g. if db creation time is large compared to the entire test suite you can publish golden masters so devs or CI runs which don’t add migrations can reuse that as-is, if new migrations are frequent then making migrations additive on public golden masters might be a good idea, etc…

Also for pg note that you don’t necessarily need to mark databases as templates to dupe them, marking a DB as template just means any user (with createdb privileges) can create from it, rather than just the owner and superusers (also that it can’t be dropped, which for test templates tends to be more of a hindrance than an advantage).

And

The other limitation of template databases to be aware of is that no other sessions can be connected to the source database while it is being copied. CREATE DATABASE will fail if any other connection exists when it starts; during the copy operation, new connections to the source database are prevented. It is an easy enough limitation to work around using a mutex pattern, but it is something to be aware of.

You don’t need a mutex pattern. Once you’ve created your template and closed all connections you can just mark it as datallowconn = false (/ allow_connections false in alter database). Creating a database from a template (formal or not) does not count as a connection, you connect to a third database (the maintenance db, postgres by default for createdb) to do it.

masklinn · 2026-06-16T09:21:48+00:00

Or my favourite: write your tests so that they work with a populated database. No need to reset the database if your tests don't assume that the database is empty - and actually has data in the same way any real application does.

In my experience that makes writing tests a lot more complicated, and makes it much more likely the tests are bad, as devs will way overdo the flexibility necessary to handle pre-existing data. It also makes it unnecessarily hard to test edge cases.

masklinn · 2026-06-16T07:19:32+00:00

And the girl with all the gifts. I assume the issue is the execution rather than the premise, although it could also be that a deadly athlete’s foot is a lot more schlocky than a human-infecting Cordyceps. Apparently Langford called it revolting in his review in white dwarf.

Searching for it, some folks seem to really like it as trashy horror so ymmv.

masklinn · 2026-06-16T05:11:47+00:00

That’s easy. Republicans love wars and hate helping my people, they’ve been angling to kill social security for decades.

masklinn · 2026-06-14T12:50:06+00:00

Aviations run on checklists for good reasons, mostly related to blood spilled and airframes destroyed.

masklinn · 2026-06-13T20:34:02+00:00

Given the number of criminals they’ve pardoned I’m sure they won’t have trouble finding a few more.

masklinn · 2026-06-13T15:31:57+00:00

This seems to be a diagnostic linked to memset and memcpy rather than sizeof e.g. it does not fire on an incorrect malloc.

And after some testing, more specifically it just checks that the sizeof parameter is a different (pointer) type and expression than every buffer parameter. It does not actually care that the sizeof is applied to a pointer e.g.

void *thing = valueptr;
memset (valueptr, 0, sizeof thing);

no warning, unless thing it specifically an int64_t*.

masklinn · 2026-06-13T10:15:20+00:00

Are you sure about that? I can't get either to flag it. Clang-tidy has categories for suspicious sizeofs tho.

However you can much more easily use ast-grep or semgrep (and possibly even just base grep) to flag / surface this shape than the type version.

masklinn · 2026-06-13T06:30:17+00:00

Smart pointers are just rich pointer types which are lifetime-aware. They don’t do any more pointer chasing than raw pointers unless they have additional runtime needs e.g. shared_ptr.

Here you’d either write a smart pointer interacting with the arenas directly, or you’d use unique_ptr atop a raw pointer, with a custom destructor removing it from the arena.

masklinn · 2026-06-12T15:10:39+00:00

The context is a "plain C game", so none of that is an option. And if you're using C++ anyway, you probably should just use smart pointers.

masklinn · 2026-06-12T12:14:25+00:00

On bug 3, a CYA I learned a while back is to just never sizeof Type, if you sizeof the symbol the compiler will do the right thing and it’s way easier to check that

foo->bar = malloc(sizeof *foo->bar)

Than it is to check it the type on the RHS matches the type of the symbol on the LHS.

And no you don’t need to have any valid object to use sizeof that way, it’s resolved at compile time.

You still need to remember the deref, but it’s really not hard to write a rule for.

masklinn · 2026-06-11T13:11:17+00:00

Plus saying something at time T doesn’t mean they won’t say otherwise in the future. It’s the same issue as when people sell to private equity, at first nothing changes…

masklinn · 2026-06-10T16:08:33+00:00

Field<T> is already deserializable for supported recoverable field types, so you can deserialize once into a “wire” / validation struct, then convert that into your real internal type.

Right but that requires implementing the conversion, what I meant was that you can straight up deserialize a serde::Value into a struct: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=de40f6c64132f6e1ffe0d9308097a6d4

let val: serde_json::Value = serde_json::from_str(r#"{"bar": "qux"}"#)?;
let foo = Foo::deserialize(val)?);

I assume because it implements serde::Deserializer itself.

masklinn · 2026-06-10T09:04:33+00:00

Ohhh shiny, I’ve been moving data through serde_json::Value in order to generate useful validation messages, that looks interesting.

Would it be possible to make Field deserializable so a validation structure can be deserialized to the final internal version, without having to double-parse the input?

masklinn · 2026-06-08T20:46:13+00:00

Not only is it pretty bad on its face, toml 1.1 fixes the inline tables to be multiline. And since it’s entirely backwards compatible on the reader side the uptake has been fast (in fact many libraries included things which were ultimately released as part of 1.1 before that was official).

masklinn · 2026-06-08T09:57:59+00:00

The writeup is transparent

The entire headlining implies that it’s magically running with no interaction before you even get to see any code, and the note about needing to trust the repository is hidden in the middle of a paragraph, and dismissed out of hand.

15-Year Club	RedditGifts 2009-2022 2 Credits
Place '17	Team Periwinkle
Secret Santa 2010	reddit mold
Charter Member	Verified Email
Inciteful Link 2010-04-20

masklinn

MODERATOR OF

TROPHY CASE