Fix 'ValueError: timestamp out of range for platform localtime() function'

[bigretromike]

Had few of those;

[winterbird-code]

Hi, and thanks for your contribution. I've never seen this error, even when parsing timestamps outside of the 1970-2038 year window. In which cases and on what platform(s) do you get this error?

I don't mind merging it, but I'd like to know why it's needed first :)

[bigretromike]

It probably something to do with python2.7 32bit. I'm not sure which date it was or which aid it was related Im fighting with encoding problem also :-) which are probably because of python2.7. If the work will go that way (as I cannot test it against 3.x I will move to python3)

[winterbird-code]

Hmm, I took a closer look at this and realized... Time is hard. I wasn't able to reproduce the problem on 32bit python2 on my raspberry pi. As far as I can tell it should be able to represent all dates between ~1901 and ~2038, and since the oldest anime on anidb is from 1907 that should be enough.

Unix timestamps are always UTC, but converting them with fromtimestamp results in a Date/Datetime object that that unix timestamp in the user time zone. Adding the seconds like in your commit ignores the user time zone. That might actually be the correct behaviour for aired/enddates, since otherwise adbb will report the day before in negative time zones. For watched/mylist-states, however, I think using fromtimestamp is more correct as most people don't want to convert UTC to their timezones manually.

Also, air/end-dates should be date objects, not datetime, as anidb does not provide more precision than days for those attributes; and that is also how the database will save the data.

So: Use date object for air/end-dates and revert the change for viewdate/updated, then I'll merge it :)

If you still have trouble with certain timestamps after that I think we should try to figure out why...

[bigretromike]

I probably overdue it with watched/mylist thing as I didn't want to hit same error; as for air/end I did hit the error. also I tested it on windows which isn't rasp os ;-) also aired is still saved to db as date not datetime; Will give you aid that throw error then

[bigretromike]

The datetime thing was for this: ed2k=3bb241d6ee5391e374e7472f3938d6f9 respond:

T001 220 FILE\n1874068|5293|80579|11274|0|0|1|322949576|3bb241d6ee5391e374e7472f3938d6f9|1550||-28425600||||||||19\n

and that throw:

ValueError: timestamp out of range for platform localtime() function

[bigretromike]

next for:

'T003 240 EPISODE\n80579|5293|25|422|2|19|The Babysitting Gangster||\xe5\xad\x90\xe5\xae\x88\xe3\x82\x84\xe3\x81\x8f\xe3\x81\x96|-28425600|1\n'

there is error:

'aired': lambda x: datetime.date.fromtimestamp(int(x)) if x and int(x) else None,
AttributeError: 'method_descriptor' object has no attribute 'fromtimestamp'

[winterbird-code]

It seems windows can only handle positive timestamps: http://bugs.python.org/issue1646728

Then we should be safe if we just use the timedelta method for air/end-enddates and let the other use fromtimestamp() as before. It looks like you mixed up what objects to use for which type in the last commit though. That AttributeError is because you no longer import the datetime module; just the datetime and timedelta objects from that module, so the import needs to be fixed.

[bigretromike]

Now this should be ok;

[winterbird-code]

No, sorry, but it still mixes datetime and date objects, and also contains some code (the encoding things) that are not related to this issue. The next time, please create a separate branch for each issue/pull request you want to fix.

I'm closing this issue now since commit 357f2de contains the necessary fixes.