Julius, On Tue, Dec 15, 2015 at 3:14 PM, Julius Werner <jwer...@chromium.org> wrote: > Okay, wrote up and tested the anchor date version. I think once you > get over the initial weirdness of the approach this one is really much > cleaner and safer. > > I tested this with the older rtc_tm_to_time() API and only ported it > over to rtc_tm_to_time64() for submission, since my 3.14 kernel didn't > have that yet... but it still compiles fine and the change was very > trivial so I'm confident that it should work. > > I also did a big manual test for my conversion functions where I just > threw a whole bunch of dates at them, results below for reference: > > [ 1.431216] jwerner: Testing translation functions: > [ 1.431221] 2015-01-01 to_rockchip: 2015-01-02 to_gregorian: 2014-12-31 > [ 1.431224] 2015-10-30 to_rockchip: 2015-10-31 to_gregorian: 2015-10-29 > [ 1.431228] 2015-10-31 to_rockchip: 2015-11-01 to_gregorian: 2015-10-30 > [ 1.431231] 2015-11-01 to_rockchip: 2015-11-02 to_gregorian: 2015-10-31 > [ 1.431235] 2015-11-27 to_rockchip: 2015-11-28 to_gregorian: 2015-11-26 > [ 1.431238] 2015-11-28 to_rockchip: 2015-11-29 to_gregorian: 2015-11-27 > [ 1.431242] 2015-11-29 to_rockchip: 2015-11-30 to_gregorian: 2015-11-28 > [ 1.431245] 2015-11-30 to_rockchip: 2015-12-01 to_gregorian: 2015-11-29 > > This one is actually a bug... to_rockchip should be 2015-11-31 here. > It happens because the "compensate if we went back over" part of > gregorian_to_rockchip() only checks whether we went over *backwards*, > which happens if the date is after the anchor date. If it was before > we can go back over forwards and I didn't bother to handle that case. > I think this is fine since all affected dates lie in the past and > there's no real-world use case where you'd ever need them to work > again.
Thanks for the testing. Ah, I see, so the problem with your patch is only right around 11/31 in years past. That seems OK to me. There's actually a real world case that's pretty common where we want to work with dates before 2016. When I power cycle my device and it totally loses battery, I notice that the firmware seems to start as: 2013-01-21 00:50:02 It's possible we could need to run for a while in this state and we possibly could even need alarms to fire. ...but that's nowhere near the problematic dates and presumably someone wouldn't have a system in the "clock set totally wrong" state for a really long time. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
