Denvercoder9

No, we just don't use AM/PM. In written language, the 24 hour format is used exclusively. When the 12 hour format is used in spoken language, we either leave it out entirely when clear from context, or use "in the morning" vs "in the evening".

So noon is "12 in the morning", which is an hour after "11 in the morning"; and midnight is "12 in the evening", which is an hour after "11 in the evening".

Don't worry, we say the same about the US, where 12pm comes before 11pm.

> If you were a human, you would have written "00:23", not "0:23".

No, I wouldn't. Leaving out the leading zero is pretty common where I'm from.

Your function converts "0:23" into "11:00 PM".

> Past/future doesn't matter

Past/future does matter, as generally speaking it's possible to accurately convert between local time and UTC for times in the past, but not in the future.

There's a few exceptions where governments have retroactively changed timezones or DST rules, but at that point you've lost anyway.

You can't accurately convert future local times to UTC timestamps yet, as that conversion changes when timezones change.

Let's say we schedule a meeting for next year at 15:00 local time in SF. You store that as an UTC timestamp of 2025-08-24 22:00 and America/Los_Angeles timezone. Now, imagine California decides to abolish daylight savings time and stay on UTC-8 next year. Our meeting time, agreed upon in local time, is now actually for 23:00 UTC.

If you're truly using Julian dates, the switch to the Gregorian calendar in the UK and US in September 1752 shouldn't affect you.

Page table layout isn't really fixed forever, x86 has changed its multiple times.

Your solution works in a geometric world, where light propagates in a perfect straight line of infinitesimally small width. That's not true in reality, where light propagates in an ever-expanding cone.

More concretely, you can have two cameras photographing along different but parallel planes that do see each other.

You don't just need the cameras to see each other, you need them to be perfectly parallel to each other as well, as otherwise they're photographing along a different plane, which may give conflicting results.

> a vertical array of distinctive marks (e.g. rapidly blinking LEDs)

This doesn't work, as light beams diverge. Even taking a high-quality laser beam with a divergence of 0.1 milliradian (for comparison, a typical laser pointer is about 1-2 mrad), after crossing the 11 meters width of a 9-lane athletics track, you end up with a beam diameter of 2.2 millimeters. At the 10 m/s speed of the athletes and a 40000 fps framerate, they travel 250 micrometers between each frame.

The necessary data rate for these photo finish cameras isn't actually that high, because every "frame" is only 1 pixel wide. If the photo is 10000 pixels high, you need a datarate of about 10 Gbit/s at 40000 fps and 24 bits/pixel. RAM is plenty fast enough for that.

Regular high-speed cameras that shoot a video are a whole other story, though.

> I also think that a .pseudo TLD should be made up which also cannot be assigned on the internet, but is also not for assigning on local networks either.

There's already .example, .invalid, .test and .localhost; which are reserved. What usecase do you have that's not covered by one of them?

I'm curious if anyone has any insights into the answer to the titular question. The article, while certainly interesting, mostly discusses workarounds, but doesn't really dive into a root cause analysis.

Closing tags and curly braces are only redundancy if the compiler/interpreter looks at both them and at the whitespace. I don't think any existing languages do that.

I suggest putting a code sample of a page written in Pretty Markup that shows off its features in the README. The documentation is currently somewhat devoid of information about the language itself.

It was probably just easier to implement. The build script[1] already has the source code, extracting the number from a comment is trivial, while retrieving out-of-band data like Caller ID from the fax server is likely more complicated. For a joke it's not compelling to do that, especially if you've already been fighting the fax server...[2]

[1] https://github.com/lexbailey/compilerfax/blob/main/build_and...

[2] https://github.com/lexbailey/compilerfax/tree/main?tab=readm...

That's the case for most, if not all, of the new European regulations, such as the Digital Markets Act. The number of companies to which it applies can be counted on your hands, and they all have tens of billions of dollars of revenue.

The answer to both your questions is yes. Wikipedia has a pretty extensive article about it: https://en.wikipedia.org/wiki/Nuclear_isomer

> A build has to pass that and then get rolled into dogfooding usage internally for a while. And then very slowly gets pushed to customers, with monitoring that nothing seems to be regressing.

That doesn't work in the business they're in. They need to roll out definition updates quickly. Their clients won't be happy if they get compromised while CrowdStrike was still doing the dogfooding or phased rollout of the update that would've prevented it.

Custom properties can be applied to any element as well. You can constrain the effects of either to only the elements they should affect in your CSS rules.

You'd have to look at purchase power, not dollars, to see how much they can actually do with all that spending. You get a lot further with $5 in a place where wages are $1, than with $20 in a place where wages are $15.

Huh, today I learned. I'll consider myself lucky I didn't come across one of these machines yet.

What kind of machines are people using that entering the UEFI boot menu is difficult? On all three of mine I just press F10 during the first 5 or seconds the vendor logo shows, and I end up in a nice menu where I could select Windows, other kernels, memtest, or the EFI shell or setup.

Home Assistant.

PostNL relabels approximately all parcels addressed to me (I almost always have to change either the delivery date or location to one convenient to me), completely free of charge.

> It was linked from the ACM or consumentenbond, or some such consumer website. I don't have the tab open, but it wasn't just a random link from Google.

Yes, it gets often quoted, but things don't become true by being often repeated. It probably wasn't the Consumentenbond, as they actively call out the list from Techniek Nederland (previously Uneto-VNI) as being too short on their website.

[1] https://www.consumentenbond.nl/nieuws/2016/consumenten-hebbe...

The term at which burden of proof shifts from the retailer to the consumer has been raised to 1 year in the EU (maybe not in the UK due to Brexit). As this is a matter of civil law, the standard of proof is also "more likely than not" proof, not "beyond reasonable doubt". You don't necessarily need an expert opinion, it _can_ be sufficient to collect a bunch of reports of similar failures.

This is not true. You have the right to a "deugdelijk product" (good product) for the entire expected lifespan of the product, and if it breaks in that, they do have to fix it (or provide a comparable replacement).

If, however, for whatever reason you don't want that, you can't demand all your money back, but only 50%. That's only if you agree to the money though, the seller can't unilaterally choose to give you 50% back instead of repairing it.

Note that this table comes from "Techniek Nederland", which is a business association of (among others) technical retailers. They've an interest in lowering the expected lifespan of appliances, as that means their members have less warranty to provide. They actually note (probably for legal reasons) along with their table that it contains average usage, not expected lifespan (i.e. how long people use things before they replace it, as opposed to how long you could use it before it breaks).

Courts will, and have in the past, throw this table out, if you make a reasonable argument why you could expect a longer lifespan.