Hi!
Or not, having an RTC set in the past is actually quite common. I'd find it weird to have a new device boot and be set to a date in the future.
...but still better than board stuck in the past, no?
Also note that the threshold or offset thing may seem like a good idea but fails with many RTCs because of how they handle leap years.
Well, you can still convert time from rtc to unix time, then do adjustment there.
You can only if your machine is running when that happens. If that is not the case, then you lost and your time is not correct anymore.
I don't see why that should be a case... as long as you know what RTC does in event of overflow, and it is not something completely crazy.
Anyway, I guess it would be cool for rtc drivers to annotate what limits underlying storage has to the common code, so that we can do fixups once per class, not once per driver.
Yes, I'm in the middle of the whole rework that allows that.
I don't understand the sudden urgency of fixing that and the amount of bikeshedding, seeing that the closest cutoff date is actually 31st of december 2069 in the rtc subsystem and that anyway the current 32bit userspace will explode in february 2038.
My plan from the beginning was to have something for the next stable. I know nobody can read my mind but again, I don't think there is currently any urgency to change anything.
Yes, mind reading is a problem. I can only read minds of ferungulates, and only if they are physicaly near me :-).
Best regards, Pavel