fix(/tastypie/fields.py): Remove usage of datetime_safe module.

[Pavankumardontha]

Fixes #1660

[Pavankumardontha]

Hi @georgedorn . Can you please check if this PR would fix the issue. ?

[Pavankumardontha]

@georgedorn Is there anything more that i need to do to fix the issue ??

[Pavankumardontha]

@georgedorn can you please once check this PR and let me know this can fix the issue ?

[georgedorn]

I don't know if this is the correct fix. datetime_safe was used for a reason now lost to time, so simply swapping it back for the python native may expose a regression. My brief skimming of the issue the Django team was attempting to fix suggests that it has not been fixed in python and that for a variety of dates before 1900 (or 1000) this may break in unexpected ways. Worse, that breakage may vary by platform, and we don't have cross-platform test support.

At the very least, we need tests showing that this works for dates where the bug is known to occur. None of the current tests consider anything before 2010.

Allowing a DeprecationWarning is preferable to triggering a regression, so until 5.0 is released and forces the issue, merging blindly is not the best option.

[benrxv]

Django 5.0 is out now. I also don't know if replacing datetime_safe with python's native datetime is correct. But what I do know is that with the deprecation of datetime_safe, Django began sanitizing datetime data to check the format, and in at least one part of their code, django.utils.feedgenerator they did in fact do the simple replacement.

Django haystack explains (far better than I) why they think replacement is fine in their project here django-haystack/django-haystack#1915 and I believe they are documenting django 5.0 support as experimental.

[georgedorn]

Implemented in #1666