The term is 漢字. It's written the same in both Japanese and Chinese, with the Japanese pronunciation being "kanji" and the Chinese pronunciation being "hànzì".
It can be written this way in Chinese (in those variants using traditional rather than simplified characters).
Whether that makes it the "same word" is a philosophical question. But writing "hànzì" is proper when referring to the use of the characters to write Chinese. If one is using it to mean a set of characters (rather than the general concept of characters that come from that writing tradition), they're different sets; and there are typically different expectations for typesetting etc. The decision to produce "CJK Unified Ideographs" in Unicode was not without controversy, and quite a few words have been spent by standards committees on explaining why these characters should share code points while there are completely separate Latin, Greek and Cyrillic scripts (despite shared history and many at-least-seemingly overlapping glyphs).
That difference in pronunciation is why “kanji”, in English, is almost exclusively used to talk about the Japanese script.
The word “hanzi” in English is much less commonly used — people studying or discussing Chinese are more likely to call them “Chinese characters” or just “characters”.
> 7.css is a CSS framework for building interface components that look like Windows 7. It is built on top of the GUI backbone of XP.css, which is an extension of 98.css.
Sort of mimics Windows itself - you famously have to do some archeology every time you want to change an important setting, and will work your way through many iterations of windows ui components as you do
Other countries have just been doing this by hand. For example, in Japan, they will open up bags of trash from the dumpster, find your address from a discarded envelope, sort out what you should have recycled, then bag it and leave it at your door, with a stern warning and instructions on how to properly sort your trash next time.
"For example, in Japan, they will open up bags of trash from the dumpster, find your address from a discarded envelope..."
Not near as prevalent as implied.
"Currently, more than half of 62 core Japanese cities are conducting garbage bag opening inspections but Fukushima's local government is the first one to disclose the names of the violators."
The waste collectors in Christchurch, New Zealand do occasional spot checks of home recycling bins and leave a little note (checklist, actually) letting you know what shouldn't have been put in the bin. They take it away regardless in the first instance; not sure what happens in the second.
Where does your intuition for how long actions take in a cockpit come from?
I'm not a pilot, so i have no idea. But from watching vasaviation on youtube, it always seems to take like 5-10 minutes between when they first radio the control tower there is an emergency, then they go through their checklists and stabilize things, and then they're ready to talk to the tower for the next step. Now add more back and forth and the time to actually fly to get back to a regular path, and 15 minutes might even seem too short a period of time before you've finished resolving everything and can now kick back and tell the passengers the end result.
I see it analogous to asking, "How much is access to the internet boosting real-world programmer productivity?" Are you really 5-10x more productive being able to google something? Couldn't you have just looked it up in the manual, don't you have peers you can ask, that's such a small portion of the time you spend coding.
But we've now lived it so much that it sounds ridiculous to try to argue that the internet doesn't really make _that_ much of a difference.
I'm 20-50x more productive today compared to 25 years ago thanks to the internet being full of open source packages that solve most of the problems I run into.
Back in the late 1990s I had to build solutions to almost every problem from scratch.
"It's difficult to quantify this, but my guess for a while has been that I've had a giant productivity boost in the portion of my job which is typing code at a computer.
And I would estimate I am two to three times more productive, faster at turning thoughts into working code, than I was before. But that's only 10% of my job."
There are lot of points in time that don't have a location, such as a historical event. Then it's most accurate to store in UTC, then convert to the timezone you want only at display time.
The author actually made the point in the beginning of the article.
> When I read Stack Overflow questions involving time zones, there’s almost always someone giving the advice to only ever store UTC. Convert to UTC as soon as you can, and convert back to a target time zone as late as you can, for display purposes, and you’ll never have a time zone issue again, they say.
But what if you're not actually storing "a point in time" but actually storing a "time at a location"? The trick is to follow the Stack Overflow advice, but just in the opposite direction. You store the time as a "wall time", and don't store a timezone or an offset, and convert it to UTC (an actual point in time) at the last minute possible.
For a given location, what timezone or daylight savings rules it's going to follow, are always up for change, so the only thing you know for sure is the "wall time" and the "location". Waiting till the last minute maximizes the chance that you've got the latest time library with the latest rules, so it follows the same principle as the Stack Overflow advice.
Now, my opinion might also be colored by experience working in the rental car industry, because the primary goal there is what the customer experiences. Because in their mind, they set up their rental in Phoenix, AZ to start at 9am, so when they're at the counter, and it says 9am on the "wall", the car better be there. They don't want to hear that time zone rules for Phoenix changed in the 6 months since they placed the rental, so "technically" their rental doesn't start until 10am. So in our database, we actually just store "07/23/2024;0900;Phoenix". It's actually incorrect to even store a timezone or an offset, because there's no guarantee those won't change, only the location won't change, so you have to do the lookup for the timezone and the rules for the given location at the very last minute, maximizing your chances of having all the latest time library updates.
The 2008 mortgage crisis is now 16 years old, and the stock market had recovered by 2011. So presumably anyone who entered the work force afterwards might have little sense of it, which would be anyone under the age of 31 (or 35 if you count college).
