I installed a search service here at DailyKos lo these many years ago and brought it through the dk3 to dk4 transition. I've maintained it all along as my contribution to the site.
Yesterday I learned that there would be a slight change made over the weekend. All internal time stamps for diaries and comments will henceforth use universal time.
Today I was informed that the change is not over the weekend after all, but before the weekend. As in, "Today". At 6 PM.
It falls to me to make sure it still works at 6:01 PM.
OK. Better get started. For a blow by blow, follow beyond the squiggle of no return.
Update: Search indexing is still not working. I knew the database time stamps were going to be UTC. I didn't expect [was not informed] that the server would also keep time in UTC. So. What I coded up yesterday didn't do the job. In addition I can't find the new database. I'm sure it will all be revealed in short order. I'm sure.
A short note: the current search is going to be replaced later this summer, as one element of a larger site upgrade. That's what I've heard. I suspect (hope?) this will take place while I'm on a sailboat in the Aegean.
Until then, how can I make search indexing work with UTC times?
The search system keeps up to date be repeatedly indexing the latest diaries and their associated comments, with a sort of sliding scale of "how repeatedly" that becomes less and less frequent as the diaries age. So I work primarily with time intervals relative to the present moment, also known as "now".
When the server time and the database time are in sync (the current situation), there's no problem.
If server time is not the same as database time, which will be true in less than 3 hours from the time I'm typing these words, then I need to tweak the code.
I wrote the search service wrapper using the scripting language Python. I recommend it for everyone and anyone interested in learning how to code.
The standard Python DateTime module has hooks for a "tzinfo" object needed to implement the sort of timezone tomfoolery required here.
But it doesn't implement it. Just specifies how it should behave. Now what?
It turns out that, as is often the case in the world of Python, there is an open source module, pytz, that implements the needed tzinfo object.
Huzza!
After only a short detour into discovering that the search server is immune to the more modern methods of Python module updates (pip? hah! I got yer "pip" right here), I download and install pytz "old school".
So, all I need to do to make this work is convert all my "naive" local times into timezone aware times, and then convert those to UTC.
I do believe I've located all the necessary code and made appropriate modifications. So when 6 PM rolls around, I'll just swap in the new versions, and you will never notice.
Possibly.
On the fly modifications of a running site always work as planned, right?
We'll see.
In any case, if your searches go a bit wonky you'll know why, and you should know I'll be here trying to fix it.
Wish me luck!
Well, that didn't go the way I expected. Which, of course is what I expected.
Since "local time" is now UTC the problem has two parts. For all indexing that uses times relative to the present ("now"), no changes are required. For all indexing based on 24 hour intervals, I need to respect the continuing priority of US/Eastern time zone and convert the 24 hour interval YYYY-MM-DD 00:00:00 - YYYY-MM-DD 23:59:59 US/Eastern to the UTC 24 hour interval YYYY-MM-DD hh:mm:ss - YYYY-MM-DD hh:mm:ss UTC.
And it will probably help to find the new database.
Working on it