Igor (BotchedRPR)Nov 13
Lynne
https://github.com/torvalds/linux/commit/f076ef44a44d02ed91543f820c14c2c7dff53716
I think about this ever so often, and I wonder, how did they fuck this up so hard?
How? The company shouldn't even exist after such a fuck-up.
rtc: rk808: Compensate for Rockchip calendar deviation on November 31st · torvalds/linux@f076ef4

In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar insufficiently represented reality, and changed the rules about calculating leap years to account for this. Similarly, in A.D....

GitHub
Nov 11 at 5:49pmWeb
Show threadjiub   Nov 11
@lynne that's one of the best commit comments i've ever seen, i'm dying
Show threadLynneNov 11
@jiub https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe
stream_libarchive: workaround various types of locale braindeath · mpv-player/mpv@1e70e82

Fix that libarchive fails to return filenames for UTF-8/UTF-16 entries. The reason is that it uses locales and all that garbage, and mpv does not set a locale. Both C locales and wchar_t are shitf...

GitHub
Show threadjiub   Nov 12
@lynne lmao holy shit
Show threadgabriele renziNov 12
@lynne wow that was a lot of angry text. Having been punished by stuff half supporting locales, I can understand the anger tho.
Show threadmuxelplexerNov 11
@lynne not just thad - they also still produce and sell that very PMIC/RTC :')
Show threadBen PfaffNov 11
@lynne It's an egregious bug in the hardware, or one might say that it is even an "egregrorian" one.
Show threadautumnNov 11
@lynne interesting. I have to admit I thought hardware clocks just counted seconds, nothing to do with calendars.
Show threadfopsNov 11
@lynne this commit is priceless. gregorian_to_rockchip
Show threadstormwoodpeckerNov 11
@lynne people will put up with a *lot* of nonsense if you can crank your chips out cheap enough
Show threadmedium rare birdNov 11
@lynne define "after"
Show threadHugo MillsNov 11
@lynne Did any of their other products have the same bug? Also, did later releases of this chip fix the bug? (Possibly silently for the exact same part number, thus ensuring maximum chaos).
Show threadpetes_bread_eqn_xlsNov 11

@lynne @djfiander

Similarly, in A.D. 2013 Rockchip hardware engineers found that the new Gregorian calendar still contained flaws, and that the month of November should be counted up to 31 days instead.

😂

Show threadErwan 🚄Nov 11
@lynne remember all the software that went down Feb 29 2024 (some already went down in 2020...)
Show threadKilla KoalaNov 11
@lynne No wonder Linus gets so sweary every now and then. 😂
Show threadJason Petersen (he)Nov 11
@lynne @misty if you think about it they’re right tho
Show threadclassabbyampNov 11
@lynne
rockchip 🤝 lesbians
bad at dates
Show thread0x4d6165 (Julie or Mae)Nov 12
@lynne WHAT
Show threadfluffy 💜Nov 12
@lynne On the plus side, whenever I worry that I might not be that good as a software engineer, I have a new reference point for comparison.
Show threadMarius KießlingNov 12
@lynne I live for commit messages like this
Show threadOzzelot Nov 12
@lynne I oftentimes think October has no business having 31 days and November only 30 (December is a blur, cause holidays fuck up any perception of time I managed to scrape up)... but I don't go into the business of implementing calendars, probably to great benefit for humanity.
Show threadPavel MachekNov 12
@lynne To be fair, time keeping is regressing globally. We used to have good local oscilators, now we have ntp.

And yes, I have smartwatch which is 'not great' at time keeping.
Show threadPavel PisaNov 12
In general, I do not understand the legacy to keep time in RTC in minutes, hours, days, months and years. Every sane system wants to run in monotonic binary time in its kernel, same for time comparison and adjustments. So ideal chip would provide some ROM field to specify its timebase frequency and then provide single binary number long enough to rollover in some reasonable time, decades, centuries. Some field to store base and some service information would worth to be added. I understand that division by 60 has been heavy deal for some 8-bit chips and even PC BIOS programmers has problems to understand how to convert monotonic time to Gregorian calendar, then the nightmare has been conservation by graphic library called Windows. This library has been replaced by real OS model obtained with DEC employee acquisition, but it keeps by default RTC in local time, adjusts its time during daylight saving period. What should do Windows laptop, when you move between time-zones??? And again there is already option in registry to keep RTC in UTC... But keeping it in some epoch based seconds or milliseconds would be much easier for everybody. All these conversion done during virtualization, RTC loads, stores....
Show threadPavel MachekNov 12
@ppisa Single binary counter does not really work well with leap seconds. Time is complex :-(.
Show threadPavel PisaNov 12
@pavel If you have somewhere defined what is the base regardless of the leap seconds then you can use leap seconds history or cumulative count. For simple BIOS like tools you can define that adjustment offset is stored in some
backed up RTC RAM register.
Show threadPavel PisaDec 3
@pavel The leap seconds are much smaller problem than attempt to convince whole world that it should update calendar by one day (edit: which is what is in the original post and I have stubled over it in another post again, so sorry for repeating)
rtc: rk808: Compensate for Rockchip calendar deviation on November 31st
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f076ef44a44d02ed91543f820c14c2c7dff53716
So I keep to vote for binary counter myself.
rtc: rk808: Compensate for Rockchip calendar deviation on November 31st - kernel/git/torvalds/linux.git - Linux kernel source tree

Show threadPavel MachekDec 3
@ppisa Yes, it could work that way. But I'm sure that if it was in use for 50+ years, someone would invent something creative to mess it up.
Show threadKateNov 13
@lynne omg, I had a laughing fit reading that 😭