As encountered in #77, there are problems comparing dates when one date has tzinfo=None and another has tzinfo=pr_time.UTC(). We intend for them to compare equal.
Since consistent tzinfo is all that matters there are a few ways this can be fixed. The easy way would be to stop using the pr_time.UTC class; omitting tzinfo in all datetime objects (tzinfo=None). According to the python documentation this implies that the datetime object is timezone 'naive', thus the timezone is not taken into account when comparing the object.
The alternative is to ensure that all datetime objects use the same tzinfo class such as pr_time.UTC(). The only real reason for this is if we need to start storing different timezone information with datetime fields in order to retain the ability to compare two dates with different timezones.
Unless support for multiple timezones in backend dates is a functional requirement my vote is to go with tzinfo=None.
As encountered in #77, there are problems comparing dates when one date has tzinfo=None and another has tzinfo=pr_time.UTC(). We intend for them to compare equal.
Since consistent tzinfo is all that matters there are a few ways this can be fixed. The easy way would be to stop using the pr_time.UTC class; omitting tzinfo in all datetime objects (tzinfo=None). According to the python documentation this implies that the datetime object is timezone 'naive', thus the timezone is not taken into account when comparing the object.
The alternative is to ensure that all datetime objects use the same tzinfo class such as pr_time.UTC(). The only real reason for this is if we need to start storing different timezone information with datetime fields in order to retain the ability to compare two dates with different timezones.
Unless support for multiple timezones in backend dates is a functional requirement my vote is to go with tzinfo=None.