I wish I had some mod points to give you. I actually chuckled at that. :)

"programming is hard because you're talking to a machine, not a fellow human"

Exactly right!

The way a computer computes and operates is largely alien to the human mind. Programming is essentially instructing an alien to perform some very specific task in often excruciating detail.

Yeah, that ain't easy to do properly.

Noice!

I've lived long enough now to see dystopian sci-fi becoming reality before our very eyes.

You have some serious mental problems.

RMS publicly admitted that he used to think adults having sex with children was okay, so long as they were willing. At the age of 66, he then "learned" that such sex can still do harm, which is one of the reasons we outlaw that. He previous thinking is one of the reasons why he didn't think there was much wrong with Minsky having sex with a minor who was being coerced by Epstein and why he effectively said so publicly on the CSAIL mailing list.

"If Kyle Rittenhouse had fucked instead of killed those two guys, that would've made them rapists, since ---according to you-- a "child" like that little prick cannot under any form consent to sex, much less initiate it or force himself upon an adult."

Yes, if a child tries to initiate sex with an adult, it is incumbent on them to turn them down, or otherwise be statutory rapists. That's the law.

If a child uses force against an adult (e.g. - a gun) and forces them to have sex, then that use of force is a crime. I doubt any court would prosecute and convict the victim of statutory rape in that situation.

You right wingers are seriously screwed up. Seek help.

And isn't just such an amazing coincidence that he suddenly learned that adults having sex with minors is bad occurred right around the time all of that crap at MIT initially hit the fan in Sept. of 2019?

I'm referring to the email chain on the CSAIL MIT listserv where RMS objected to the language that Minsky "assaulted" Giuffre because she in all likelihood (in RMS' estimation) presented herself to him as "willing" in their sexual encounter.

RMS then went on to say that "it is morally absurd to define 'rape' in a way that depends on minor details details such as what country it was in or whether the victim was 18 years old or 17."

If you think I have misrepresented RMS' views on pedophilia, then maybe you will accept them directly from the horse's mouth instead:

https://www.stallman.org/archi...

"14 September 2019 (Sex between an adult and a child is wrong)

Many years ago I posted that I could not see anything wrong about sex between an adult and a child, if the child accepted it.

Through personal conversations in recent years, I've learned to understand how sex with a child can harm per psychologically. This changed my mind about the matter: I think adults should not do that. I am grateful for the conversations that enabled me to understand why."

"... played devil's advocate ..."

No, RMS was not playing devil's advocate. He was giving his honest opinion that if a minor consents, then an adult having sex with them does them no harm, is not assault, nor rape -- regardless of the law on the matter.

Apparently, at some point after publicly advocating such a position in regards to Minksy + Epstein had torched much of his reputation, he then "learned" at the age of 66 (Sept. 14th, 2019) that he was wrong. That such pedophilia can do harm to the children involved and that "adults should not do that."

He has (had?) similarly troubling opinions on child pornography. That, in his view, the possession of such material does no harm to children, so it should not be outlawed.

This is the guy you are trying to protect. And that's just the tip of the iceberg in the unprofessional way he has conducted himself with regard to sex for decades.

If an entire movement lives or dies on the reputation of a single person, then it is incredibly fragile and will very likely fail.

I disagree with your assertions that effectively RMS is free software and free software is RMS and that one cannot succeed without the other. The graveyards are full of indispensable people.

"... especially repair and return RMS in good standing."

The controversy was originally created by RMS' actions and statements over many decades and the institutions around him turning a blind eye towards them.

The current conflagration of the FSF is only because RMS chose to reinsert himself back onto its board. If he had stayed away, then none of this would be happening. If he actually cared about the FSF and its mission, then he would have already resigned again and carried on his work separately somehow.

"... who only cared for their chair ..."

They cared so much about their chairs that they resigned them?

"Well, if you venerate Gandhi or Theresa and despise Richard ..."

That is a strangely specific application of whataboutism.

"Richard Stallman is a sexist?"

That is one of the charges amongst also being transphobic and ableist over many years too.

Personally, the most troubling bits for me are his views on pedophilia, statutory rape, and child pornography. Until very recently, he thought that so long as the child was willing, then there was little to no harm at all with an adult having sex with them. On child pornography, he thought that while the act of taking the pictures might be illegal, that possessing the pornography did no harm and shouldn't be illegal.

Allegedly, he recently (i.e. - Sept. 2019) learned that he was wrong about pedophilia and changed his mind. The fact that he allegedly had to "learn" this at the age of 66 is ridiculous to me. No, that was just a slight surrender on an untenable position and CYA.

The fact that he doesn't see any problem with possessing child pornography again highlights a deeply troubling worldview. He doesn't seem to understand that those who seek to possess such pornography create a demand for its creation and the harm to children that causes. Or is this another untenable position that he "recently learned" was wrong and has recanted?

then he would have already resigned by now simply for the damage his presence is doing to the overall organization -- whether that damage and him leaving was justified or not.

The way it is going now, the FSF is going to be reduced to a smoldering ruin because of Stallman's returned presence.

My thoughts exactly! Standard time during winter is atrocious. It gets dark by 4:30pm.

> If timestamp arithmetic is destroyed this easily, then it has been destroyed already.

Yes, although not for the reasons you state. If you try to do Unix timestamp arithmetic between now and, say, 20 years from now, then your interval will be wrong by however many leap seconds are added (and/or removed) between now and then. We've been averaging a leap second every ~1.5 years. If that keeps up, then you'd be off by ~13 seconds of real SI time.

> Computer clocks drift over time. They can't maintain sub-second accuracy without constant contact over Internet to those expensive atomic clocks.

Those are true statements, but irrelevant to the question at hand. If we don't care about accurate time keeping, then, sure, who really cares? Yes, your application is likely to be wildly off over long stretches of time.

We are discussing applications that do care about fidelity to real time and calendar time too, which is actually most applications. Every such machine + application must keep in regular contact with a true clock or it too can be wildly off over long stretches of time.

> In practice, leap seconds can be handled just like those usual NTP clock calibration

What you are saying here is that leap seconds aren't real seconds and can effectively just be ignored. If that were the case, then all of the leap second smearing hacks that most people use these days to handle this problem wouldn't exist. We'd still just be in the bad old days where the clock abruptly stepped back (or forward) 1 second at random-ish intervals even when you were directly connected to an atomic clock.

> If such compensation is not implemented in the computer/smartphone (why spend the money on something most don't care?)

You seem to think that most (Unix) computers and smartphones don't care about keeping pretty accurate times and dates. I disagree.

> Due to clock drift and resynchronization, one second of computer timestamp interval is already IMPOSSIBLE to be promised to be one SI second long, even if UTC and leap second disappear from Earth.

That's somewhat true, but your argument is effectively "let the perfect be the enemy of the good." If we can't have perfection, then introducing gratuitous errors is just fine and dandy. Again, I disagree.

In particular, if you are regularly synchronizing to a true clock by regulating clock frequency and slewing it to correct errors, then while it is true that this "second" versus that "second" on the machine can both be different than actual SI seconds, that error gets spread out, diffused, and effectively eliminated over larger and larger spans of time.

> A timestamp can't be both accurate and precise

Do you mean in a single number? Because a UTC timestamp can be both accurate and extremely precise.

> In your proposal of doing timestamp "in UTC", I guess you mean a computer string. Updating a datetime string takes time. That time is not constant ... Thus the raw value of a computer internal clock, above a certain precision, cannot be UTC string but must be simple number.

First off, there is no ambiguity in representing a timestamp in TAI in a single number for times in the past. Such a timestamp can unambiguously and accurately be mapped directly to a proper UTC datetime (e.g. - for display) and vice versa. So, for things like file timestamps, you can just use TAI timestamps and you are golden. Indeed, I'm arguing that TAI should be the system time rather than Unix time.

The problem only comes in when you want to represent and/or hit a UTC time in the future. Then, there isn't a 100% accurate way to represent that time in TAI because UTC might decide to add in seconds (or not!) between now and then that we can't know about a priori. The best way to represent such a UTC time is directly in UTC. That could be in a string, but more likely it is in a structure that decomposes the timestamp into its multiple numeric fields like Posix C's struct tm in time.h. It's true that doing math with such a beast is more difficult than a single number, but there are various ways to minimize the storage and computational overhead of dealing with UTC timestamps.

Besides, the math you are doing with your Unix timestamps is already wrong as I said. Leap seconds are real and shouldn't just be ignored.

Or, if you / your application doesn't care about being off by a second here or there as you keep arguing, then just represent future times in TAI too and accept that you will be off by the leap seconds. For your applications that might be good enough. For others that really care about accurate times, then they need to be aware of leap seconds and deal with them, which is also true when using Unix time.

> if you use TAI as internal clock as like your proposal, you can still be screwed if you program naively in the thinking that "countdown for X seconds" can be done accurately

As I said, for tracking passage of time, you should be using monotonic clocks that are not subject to jumping. They are only affected by slews in the clock frequency correcting for errors.

If your application wants high accuracy in waking up / hitting a UTC time, then you need to be even smarter than just "sleep for X seconds," which is wrong for both Unix and TAI time. Instead, you need a library that is aware of and monitoring for both clock jumps and leap seconds and will make ongoing adjustments to when you should actually be woken.

> Sorry, as long as users want to [represent] UTC time in computer by a single number ...

That's impossible to do well for future times because UTC sprinkles in and removes random-ish extra seconds here and there as time passes. If you want to represent a UTC time well, then you need to do it in UTC, which has multiple time subcomponents and accounts for leap seconds. You can't boil all future UTC times down to a single number well a priori due to UTC's fundamental definition.

If you try regardless, then you will cause all the craziness and heartache that comes from Unix time! That's the main point I'm making!

Unix time screws with our entire conception of time because it wants to make the representation of dates ever so slightly simpler: a single number rather than a UTC timestamp. And it doesn't even do that well because the mapping is ambiguous (not 1-to-1 in both directions) and you can't do proper arithmetic with the numbers anyway as the timeline now has loops and holes in it (or, if you smear, seconds that aren't actually seconds on days with leap seconds).

> What will happen when one use TAI to record timestamps instead? One will become IMPOSSIBLE to convert a future UTC time into that number.

Yes, because that's the actual truth of the matter! You can't always know a priori when the leap seconds will be declared, so there is no good way to convert a future UTC time into a single number well. Unix time tries to achieve what you want by screwing with our base conception of what a second is and destroying timestamp arithmetic all because it wants to represent something in a single number that can't be done well. That's a terrible decision.

Here's a crazy idea: if you care about representing or hitting a UTC time, then keep your time representation in UTC! Yes, there is some heartache that needs to be handled by system libraries in how do I convert my system (TAI) time into a UTC time and vice versa. You are correct that even these libraries can't do this perfectly for all future UTC times in a single go because of the random-ish leap seconds that will be inserted or removed into UTC over time. That's fundamental to the definition of UTC.

So, if I need to represent a date like 2050-01-01 13:00:00, then my preferred representation should be in UTC itself. If I need to set a timer to go off exactly then with an interval specified in seconds, then I need to make a conservative estimate that will wake me up early but close enough to that time that the presence / absence of leap seconds can be realized and accounted for and I can adjust my sleep interval to actually wake me up on time. If this is a common case, then we should build a library and API that allows us to specify absolute UTC wake times and handles all this ugliness for us under the covers.

Again, you actually need to do something similar in Unix time regardless because the interval in seconds that you compute today by subtracting your future timestamp from your current timestamp will be wrong. Or, alternatively, the system screws people who really want to sleep for X seconds to instead sleep for X + leap seconds instead. Making that latter decision is, again, crazy.