I am also curious to know if having the system clock in UTC and storing times using UTC, which I understand UNIX-based operating systems do, avoids these types of issues. It should make them easier to manage, is my guess.
A) you need the new timezone definition available and pushed everywhere regardless. It doesn't matter what zone the RTC uses.
B) For future events, you need a way to manage what happens when the time zone they're scheduled in changes OR when they change to a new time zone. Microsoft has been terrible at this part on every time zone change I've been aware of (it's hard, but it's not this hard, and the Canadian change was published with sufficient notice, and time zone changes happen for recurring events, this is not a new requirement). But there's no connection to the time zone of the RTC here either.
If you have issues with poor behavior specifically around transitions, that could be related... Repeatedly moving forward or backward for DST is something where keeping the RTC in UTC would help.
For past events, you can certainly store them as UTC and (possibly implied) location, provided that you also have a historically accurate database of all past time zone changes, so that you do not report that a meeting took place at 9:00 when it actually happened at 10:00, but the current time zone rules (at that location) are not the same today as they were on that date in the past.
For future events, you have to store them as location + timezone-naive dates and times, a.k.a. local time. Since if a meeting at a certain location is scheduled at 9:00, which is currently at 02:00 UTC, and then a timezone change happens, and UTC 2 suddenly means 10:00 at that same future date and location, the meeting will still happen at 9:00 local time. You cannot store future events as UTC only.
UTC brings its own batch of problems when it comes to local time relative scenarios.
Last time I looked best practice for a real calendar app was to store in local time with time zone, not UTC with offset.
UTC is time in theory. Points in time separated by numbers of seconds. Great until the reality of time being a social construct breaks your assumptions. Still, use UTC until you are actually building a calendar app. Depending on your use case, consider storing timezone instead of offset.
Either UTC or TAI should be used for anything that is truly a "time".
The "time" at which future events are scheduled by humans (i.e. not the time when future events are predicted, like astronomical events), is not a "time", but it is a different data type, which must have a different name and which must store different information (i.e. legal date and time at a certain location).
As another poster already said, UTC is the correct choice for any kind of timestamps and for the storage of any time information about the past. (Actually TAI is an even better choice for these purposes.)
For future events, the "time" when they will occur is not "time", but a different data type, which should be called "legal time", "local time" or the like.
The "local time" for future events must include the geographic location attached to the event, from which the applicable time zone can be derived, at a time close to when the event is due.
This week, I asked Claude Code to generate an MD to continue working on another computer, without losing the context, and it refused claming some sort of extraction. It was only until I selected Opus, that it completed the request.
I can only think of Edsger Dijkstra's quote: "Program testing can be used to show the presence of bugs, but never to show their absence [...]". Adding that computers are mathematical models and Gödel's incompleteness theorems stating that a system cannot demonstrate its own consistency, I would say that it is likely that bugs/errors will always exist.
The theorem can be used un this way? Wasn't only for natural numbers? You argument seems solid if thats how the theorem works. Maybe there is a way not to find Bugs but to build things perfectly from the start.
My understanding is that the theorems apply to any "formal systems". If my assumptions of computers being part of "formal systems" is correct, then the theorems should apply, per my understanding.
I have heard from some power users that Brave is one of the best browsers with regard to ad-blocking and privacy.
But I think I have read elsewhere that it receives money from ad companies to display only certain ads, which does not make me trust it.
Does anyone have facts or know where to find them?
As a general role, always be suspicious of very loud and vocal opinions about product and services. Specially for closed source products and paid services, they often invest in what is called Native Advertisement/Marketing which is basically paying people to lie and pretend it is organic content/opinion.
Second, despite the dumpsterfire that Mozilla’s leadership has been in a decade or so, it is very robust with privacy and anti fingerprint features out of the box, the containers has also stabilised and works great.
I see so many misconceptions on HN about that coveryourtracks site. Neither of those results are ideal.
"randomized fingerprint" -> that's a bad result, it means the site can detect you're spoofing info
"unique fingerprint" -> this is good, ONLY IF you refresh and it still says "unique fingerprint", because it means the site sees you as a brand new visitor each visit, and doesn't detect any (what advertisers would call) nefarious behavior. however, if you visit again and the second time it says "nearly-unique fingerprint", that's a fail because your two visits were linked
The ideal result you should aim for is "non-unique fingerprint". That means your device is indistinguishable from countless others. Blending in to the crowd is what you want.
These tests aren't reliable - Brave does randomise values but it ultimately doesn't do much to prevent fingerprinting, as many values remain static. For example, Brave still exposes your GPU model and driver version.
See Fingerprint.com, despite Brave's protections you'll likely find it works reliably.
Something that Spanish has, that your "vi a Fred" example reminded me of is that when the direct object of a sentence is a person, you use "a": "vi a Fred", "escuché a mi mamá".
Unlike unhuman objects: "vi el carro", "escuché un ruido".
I watched this movie and missed that this was mentioned. Funnily, I am from and live in Nicaragua and find it funny that we have no such land formation. I am assuming that is the point you are trying to make.
> I am assuming that is the point you are trying to make.
Not exactly. My point is that LLMs dramatically increase the danger and risk of certain types of manipulation, fraud, and brainwashing. Those things will become much easier to do cheaply and secretly and at a large scale.
The Truman Show offers a useful way to convey those kinds of risks, but the details of the product being sold doesn't really matter, we just need to know that the company is willing to do those kinds of things.
> no such land formation
I'm sure the script-writers knew this. I believe they chose it because they wanted to make a satire (mocking joke) of real-world coffee-products being sold at a certain time, but did not want to include details that that some real-company (or country) could get too angry about.
reply