Obviously it would be better if you know where the JSON comes from, and can look in the docs/ask the author/etc. to know what the actual intention is behind that date format. (It might even be generated by Python code, using a library you can just use yourself…)
But looking at the numbers, I can make a pretty good guess what this means: the 1405961743000
is milliseconds since the Unix epoch (which explains why you can use the first 10 digits of it as seconds since the Unix epoch, at least within a pretty wide range around 2014), and the +0100
is a timezone offset from GMT, in +HHMM
format.
So, instead of extracting the first 10 digits, converting to int, and calling fromtimestamp
, you'd want to extract everything up to the +
or -
, convert to int, divide by 1000, and call fromtimestamp
. Although the fact that the only example you've given us happens to have 0 milliseconds implies that there's a good chance they all will, in which case this difference won't matter…
Anyway, it's then up to you what to do with the timezone offset. Do you want to store aware local datetimes? GMT datetimes? naive local datetimes? They're all pretty easy to get to from a timestamp and an offset (although "aware" is going to mean using a fake timezone like GMT-05:00, which doesn't have any historical or DST information, of course), but you have to decide which one you want.
Whatever you end up doing, you may want to consider extending your JSON decoder to automate it, as shown in the examples in the docs. (Any string that matches the regex r'/Date\((\d+)([+-]\d{4})\)/'
, the first group is the timestamp and the second the offset.)
But maybe not. Especially since parse_string
doesn't seem to be overridable, at least as of 3.4, so it looks like you'd have to monkeypatch it. See this code I slapped together as a proof of concept; you might be able to make it a little nicer, but there's a limit to how clean you can make it if they didn't provide a hook for it…
PS, if you're ever extending JSON yourself, you may want to consider a more standardized and self-documenting way of doing this. The dict format shown in the json
module docs, where you effectively specify a constructor to call and the arguments to pass it, is a lot easier for people to figure out (and to add a hook for). Or, alternatively, there's a quasi-standard way of encoding YAML formats as JSON formats, and YAML is extensible (and already has a standard timestamp extension).