That's no curse, it's a protection hex!
It seems great that an app without location access cannot check location via EXIF, but I'm surprised that "all file access" also gates access to the metadata, perhaps one selected using the picker.
https://gitlab.com/CalyxOS/platform_packages_providers_Media...
Perhaps it is mm/dd/yyyy (really?!?) that is cursed....
Note the slashes are important, we don't use dots or dashes with this order. That's what GP was getting at.
But, I think the American-style formatting is logical for everyday use. When you're discussing a date, and you're not a historian, the most common reason is that you're making plans with someone else or talking about an upcoming event. That means most dates you discuss on a daily basis will be in the next 12 months. So starting with the month says approximately when in the next year you're talking about, giving the day next says when in that month, and then tacking on the year confirms the common case that you mean the next occurrence of it.
When's Thanksgiving? November (what part of the year?) 27 (toward the end of that November), 2025 (this year).
It's like answering how many minutes are in a day: 1 thousand, 4 hundred, and 40. You could say 40, 400, and 1000, which is still correct, but everyone's going to look at you weirdly. Answer "2025 (yeah, obviously), the 27th (of this month?) of November (why didn't you start with that?)" is also correct, but it sounds odd.
So 11/27/2025 starts with the most useful information and works its way to the least, for the most common ways people discuss dates with others. I get it. It makes since.
But I'll still use ISO8601.
As a US native let me clearly state that the US convention for writing dates is utterly cursed. Our usage of it makes even less sense than our continued refusal to adopt the metric system.
If you wanted a short form to match the word form, you go with something like:
“mmmm/dd/yyyy”
Where mmmm is either letters, or a 2-character prefix. The word form “August 7th…” is packing more info that the short form.
https://wikipedia.org/wiki/Date_and_time_representation_by_c...
IMO the best format is yyyy/mm/dd because it’s unambiguous (EDIT: almost) everywhere.
> Short format: (yyyy.dd.mm) in Kazakh[95][obsolete source]
ISO-IR-26 was registered on 1976/25/03.
Uh... good?
I might not want an application to know my current, active location. But it might be useful for it to get location data from images I give it access to.
I do think if we have to choose between stripping nothing or always stripping if there's no location access, this is the correct and safe solution.
This is a good example of a complex setting that makes sense to the 1% of users who understand the nuances of EXIF embedded location data but confuses the 99% of users who use a product.
It would also become a nightmare to manage settings a per-image basis.
That said, an alternative to bugging the user might be that when the app makes the call to open the file that call should fail unless the app explicitly passes a flag to strip the location data. That way you protect users without causing needless confusion for developers when things that ought to "just work" go inexplicably wrong for them.
1 - https://github.com/savely-krasovsky/immich/commit/aeb5368602...
Is this true? I couldn’t find another source discussing it. That would be insane behavior for a package manager.
- macOS data forks, xattrs, and Spotlight (md) indexing every single removable volume by default adds tons of hidden files and junk to files on said removable volumes. Solution: mdutil -X /Volumes/path/to/vol
- Everything with opt-out telemetry: go, yarn, meilisearch, homebrew, vcpkg, dotnet, Windows, VS Code, Claude Code, macOS, Docker, Splunk, OpenShift, Firefox, Chrome, flutter, and zillions of other corporate abominations
By default, telemetry data is kept only on the local computer, but users may opt in to uploading an approved subset of telemetry data to https://telemetry.go.dev.
To opt in to uploading telemetry data to the Go team, run:
go telemetry on
go telemetry off
05/26/23(?) Datetimes in EXIF metadata are cursed
From the linked GitHub issue comments, it looks like they adopted the sensible approach of refactoring their ORM so that it splits the big query into several smaller queries. Anecdotally, I've found 3,000 to 5,000 rows per write query to be a good ratio.
Someone else suggested first loading the data into a temp table and then joining against that, which would have further improved performance, especially if they wrote it as a COPY … FROM. But the idea was scrapped (also sensibly) for requiring too many app code changes.
Overall, this was quite an illuminating tome of cursed knowledge, all good warnings to have. Nicely done!
I'll give you a real cursed Postgres one: prepared statement names are silently truncated to NAMEDATALEN-1. NAMEDATALEN is 64. This goes back to 2001...or rather, that's when NAMEDATALEN was increased in size from 32. The truncation behavior itself is older still. It's something ORMs need to know about it -- few humans are preparing statement names of sixty-plus characters.
For me, MacOS file names are cursed:
1. Filenames in MacOS are case-INsensitive, meaning file.txt and FILE.txt are equivalent
2. Filenames in MacOS, when saved in NFC, may be converted to NFD
$ echo yup > README.txt
$ cat ReAdMe.TXT
yup
$ ls
README.txt
Those classes can call stored procedures or functions.
Those classes can be called BY stored procedures or functions.
You can call stored procedures and functions from server-side Java code.
So you can have a java app call a stored proc call a java class call a stored proc ...
Yes. Yes, this is why they call it Legacy.
treve•4h ago
Centigonal•4h ago
godelski•1h ago
I'm big on Hanlon's Razor too, but that doesn't mean the end result can't be the same.
smitty1e•4h ago
Especially if you could control at install time just how far back to go, that might be interesting.
Also an immediately ridiculous graph problem for all but trivial cases.
fastball•3h ago
0x696C6961•2h ago
bikeshaving•3h ago
treve•53m ago