A Saturday waste of CPU cycles: building time_t values
About ten years ago, I was big on RSS and Atom feeds and followed a bunch of them regularly by way of Google Reader. I knew from having been inside the company that it was doomed. It had been destaffed for a good while before I quit, and figured the other shoe would drop eventually. In March of 2013, it did.
In between those points, I got annoyed with depending on them and wrote my own thing to go out and fetch feeds and then render them in a way that was quick and painless. It had the absolute minimum amount of stuff visible, and gave all but the very top of the page over to the content.
While doing this, I wound up discovering how crappy some feeds truly are. There were all kinds of feeds which did something strangely, and I encountered a whole slew of date formats.
My goal in this was to turn these human-readable date strings back into a time_t value so they could be stored sanely in a column in my database. This way, if the post was revised, that value would change, and I'd show it again. Otherwise, it would be discarded so as to not fill my database with a bunch of duplicates.
It was bad enough trying to split up all of those date strings into their constituent parts - year, month, day - all of that stuff. But, then when I tried to consistently turn them back into a time_t, I ran into a bunch of other problems. That lead to the post called time handling is garbage. That then lead into the followup post three months later which talked about making time_t values without using mktime and the TZ variable.
Given that it was written for the feed reader project, and that was what people had voted on for me to do as a Kickstarter project at the time, the catch was that it would be open-sourced when the rest of the project was. Of course, then the Kickstarter didn't reach its goal, and nothing happened. It faded away in the summer of 2013.
And so, a couple of days ago, I did exactly that.
So in a twisted way, I have now released the routine which does this.
Incidentally, watching it run showed me a few things which I never thought of initially. When it's adding each year's worth of seconds, watch what happens to the month and day fields! You should notice that they tick down at about 1/4 the rate that the year ticks up. That's because it first adds 365 days per year, and *then* it goes back and does a fixup for the 4, 100, and 400 year rules.
And yes, the 100 year rule is a *negative* fixup, so if you give it a date that crosses one of those years (try anything above 2100), then you may catch it stepping the day backwards at that point.
I will point out that as part of my "fun" directory, this is supposed to waste human time, CPU time, and bandwidth. It's not supposed to be directly useful. But, hey, if you want to look at the code and copy the technique, go for it. If it helps you out, great!