Strange clock issue

Wow ok, now that is strange. I wonder whether there's been some kind of overflow somewhere in the RTC - if it had suddenly jumped back in time then that would probably explain the software follower's speed changing drastically.

I don't suppose you ever logged getTime() anywhere before this happened?

Having looked into the code, I have a theory as to what might have happened. On the STM32F4 there's a proper hardware RTC which includes day/month/year - which makes getting the actual timestamp out of it kind of painful.

It looks like I hadn't taken account of the fact that the month is 0-based in Espruino's Date implementation, but 1-based in the RTC itself. It means that 'January' is actually 0, which is out of bounds, so if the date was Jan 30, that'd indicate some kind of RTC error.

But even without that, if the date were moving between months and Espruino thought the current month had 31 days when the hardware thought it had 30, that'd cause a massive jump.

I've fixed this now, so the latest travis builds will hopefully be better. I'm amazed this never got spotted before though - I guess the F1 and nRF52-based parts don't have the issue because their RTC is just a counter, without the whole calendar part in it.