>Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that.
Making an assumption that a day 86400 seconds breaks at least twice a year in many parts of the world, and that's before we introduce leap seconds or possibility of your code running on hardware that itself travels across timezones.
Technically, nobody lives in "UTC". You might say people live in UTC+0, which is a standard time zone around the prime meridian. UTC refers to the system of standard time zones, not a single time zone, but in common speech "UTC" is often understood to mean UTC+0.
Let's say you live in California. During the winter, you observe PST ("standard time"), which is UTC-8. During the summer, you probably observe PDT ("daylight time"), which is UTC-7. Switching between the two is sort of outside the scope of the UTC system. It happens locally and is subject to local social and political preferences. Digital clocks mostly just keep track of standard time and possibly adjust their output if presenting a human-readable timestamp string.
Leap seconds are very much inside the scope of UTC. A leap second occurs globally for every standard time zone at the exact same global instant. It's determined by an objective criterion based on UT1.
I've implemented exactly the filter you're describing. Yes, it's essentially a presentation issue.
There are 2 common ways to represent time: something akin to Unix time, which is just a scalar number representing the offset from some global reference instant (the epoch), or as "clock-calendar parameters" i.e. year-month-day-hour-minute-second. It's much more natural for software to operate entirely on the former representation right up to the point that the timestamps need to be either displayed as an output string for a human to read, or parsed from an input string from a human. Then you crack open tzdata [1] to do the conversion.
I think if your definition of "presentation" includes "parsing"; then we have very diverging definitions; but at least I understand we're mostly on the same page.
I programmed systems with both for many years -- the thing that needs to be defined early is whether your time an Instant or a Date/TimeOfDay/Quarter (collectively Naked)
Instant would be like log entry timestamp. Can be represented as unix time or SQL Timestamp.
Naked would be a "contract effective date" or "employment first day" or "invoice date" or "store opening time". Do not try to use an Instant to store it (e.g. timestamp at midnight to represent a day) or you're about to have a bad time later.
Instants are more prevalent in systems engineering, Nakeds -- in applications.
Only when you need to present the Instants to the user you need to convert them to strings and timezones come into play. Nakeds rarely need to be translated to Instants (e.g. when deciding if an invoice is overdue and send a email notification).
I don't think the "new" Performance cores are just "renamed" "E" / "Efficiency" cores; Apple has retroactively renamed the baseline M5 nomenclature to say it has "10-core CPU with 4 super cores and 6 efficiency cores"; so they're clearly keeping the "efficiency cores" nomenclature around.
I think this is a new design, with Apple having three tiers of cores now, similar to what Qualcomm has been doing for a while.
I think how it breaks down is:
- "Super" are the old "P" cores, and the top tier cores now
- "Performance" cores are a new tier and seen for the first time here, slotting between "old" P and E in performance
- "Efficiency" / "E" are still going to be around; but maybe not in desktop/Pro/Max anymore.
Interesting. This is clearly a big CPU change if so. I wonder why no E cores. I’m sure E cores would be more efficient at OS tasks than the new performance cores.
For example, 6 super, 8 performance, and 4 efficiency.
I was gonna be a smartass about how in my native language it would count as three words; but then I went and consulted Wikipedia and it was so dense with linguistics jargon I realized I actually have no idea what a "word" is.
But the consensus seems to be that in English that would indeed count as four words ;P
I had to _call_ my German provider to get a new eSIM.
Meanwhile, my carrier in Japan not only migrates eSIMs between phones with no issues; it even offered to migrate my wife's physical SIM to an eSIM when setting up a new phone; and it worked flawlessly.
The way my original eSIM here was provisioned was also surprising to me, in a "I didn't even know this is possible" way.
When signing up for a contract, I just put in my eSIM EID, and then a couple of hours later an eSIM was _pushed to my phone by the carrier_; without me having to do anything (other than confirming that I do want to install it). Lots of customer-facing telecom infra here is pretty bad; but the eSIM experience was as good as it gets.
And why is it broken? Is there a way for a password manager app to somehow inspect other apps and identify forms within them and interact with the forms?
...yes? I can't tell if you're trolling at this point or genuinely unaware.
Both iOS and Android have APIs for this, you (as the app developer) just mark the relevant fields in the app as login/password/etc, and the OS will interact with your chosen password manager to autofill and/or save them.
If you've never seen this work on your device, then you might have something configured incorrectly — many app developers are incompetent and bad at this; but not _all_ of them.
It works for filling an existing password, but not for creating a new one, iOS still prompts me to fill existing even though I'm on the sign up page. On the web 1Password can also automatically generate a Fastmail masked email address, but I doubt there's any hope for that to work in a native app.
He has something to do with this show as well which was obtuse enough to keep me at a distance. It's an unhinged, detective story with puppets in a noir-laden city grit setting.
I need to get around to Perpetual Grace; I've watched the first 15 minutes of it like four times and always ended up bouncing off of it for one reason or another; but I know if I got into it, I'd probably really dig it.
Funny thing about watching Patriot for the first time: my sister in law showed up on it. We had no idea. Just all the sudden there she is on my TV. She's the mute cop, Sophie.
If the first episode doesn’t draw you in, it’s probably not your kind of show. I’m not saying episode 1 is all it has to offer, but if you don’t enjoy episode 1 it’s doubtful you will enjoy the rest.
If you use the _digital_ MyNa card (e.g. the one in the Wallet.app; not the plastic one); the iOS SDK lets you only request the "is user more than XX years old" flag; without getting the actual identity: https://developer.apple.com/documentation/passkit/requesting...
Now, AFAICT nobody actually does this, but the technical ability is there.
Discussions about this are very tedious, because people have hard time making distinction between "being able to see the difference between 1080/4k/8k content" and "being able to see the difference between 1080/4k/8k panels".
I'm sure there's plenty of content (especially streaming content in mediocre bitrate) where people would be hard-pressed to tell the difference.
But I think if people went back to 1080p _panels_; they'd actually rather quickly notice how much worse the text-rendering is, and that the UI looks off for them.
Moving up to 8k would definitely be a smaller step-change in clarity than 1080p->4K and many people wouldn't feel it's worth spending extra; but I don't think it would be literally indistinguishable.
Making an assumption that a day 86400 seconds breaks at least twice a year in many parts of the world, and that's before we introduce leap seconds or possibility of your code running on hardware that itself travels across timezones.
reply