The best solution here is probably to have your jQuery
code convert its datetimes to GMT before sending them. (If you want the timezone as well, send it separately.) Then you can get them out of the JSON (or whatever) on the Python side, turn them into GMT datetime
objects with strptime
, and use them, and you're done.
But the simplest solution,* with the least code change, is to just let jQuery do the wrong thing and throw away the timezone on the Python side. Basically, instead of this:
dt = datetime.datetime.strptime(jsondate)
do this:
dt = datetime.datetime.strptime(jsondate.partition('(')[0])
Notice that throwing away everything after the '('
still leaves you with the -0600
part; you're just losing the "PST" or "Mountain Daylight Time" part.
And those parts were not doing you any good anyway. datetime
doesn't understand these timezone names. And, even if it did, it has nothing to map them to except for offsets (which you already have). If you want real timezones, you need some third-party library like pytz
.**
On top of that, strptime
specifically returns naive datetime
objects, not aware ones. So, even if datetime
could parse and look up the timezones, it still wouldn't do anything useful with them, unless you parsed the datetime
, then pulled out the timezone and parsed it separately and looked it up and then called astimezon
on the datetime
.
So, in summary, the worst-case scenario for throwing this information away is exactly what you already have.
As a side note, on three projects in a row, I pushed a datetime serializer into my JSON en/decoder on the Python side (and a matching serializer on the JS side, for the one that had a JS side) specifically so I could pass a UTC datetime (in ISO8601 format, because that's as easy to use for computers as a seconds-since-epoch, and a lot easier to read/edit for humans) and a timezone offset today, but switch to a tzinfo key if it because important later. All three times, it never became important… And the projects where it has been important, I've usually been passing around ICAL schedules or pre-Gregorian dates or other similarly fun stuff.
Finally, as someone who's written way too much date-related code over my career, I have to say this: If you know of any evil overlords planning to take over the world, if they promise to abolish timezones, I am willing to overlook their other programs of enslaving humanity or making kittens fight babies and sign up as a henchman.
* … at least simplest for me, since I know Python a lot better than JS and jQuery. :)
** IIRC, pytz
can't handle NT-style timezone keys like "Mountain Daylight Time" either, so you actually need yet another library to handle that. I think I got that out of a library that did all kinds of MS datetime stuff, including handling the differences between Microsoft's three similar 1601-ish epoch times (two not-quite-the-same epochs, different rules for special "end of time" and "start of time" and "not a date" values, …).