[Pulp-list] [dev] create custom mongoengine field for datetime?
bbouters at redhat.com
Mon Nov 23 17:45:57 UTC 2015
In converting to mongoengine, we have not yet thought through this
problem. I agree with your two approaches and assessment.
Using the UTCDateTimeField is a good short term solution because it will
be simple to implement. By doing the timezone conversion in to_python()
we can avoid littering the code with calls to ensure_tz(). The models
will need to switch their field type to the UTCDateTimeField, so we'll
know exactly where it is/isn't used.
Then over time, we can reduce usage of UTCDateTimeField. Long term, I
think pulp should use non-timezone aware, UTC for everything. Eventually
we could remove UTCDateTimeField. What do you/others think about this
Note, the ISO8601Field will still work the way it does here with its
custom field definition.
On 11/23/2015 12:04 PM, Michael Hrivnak wrote:
> Following up on this: https://github.com/pulp/pulp/pull/2067/files
> ... the problem seems to be that mongoengine's DateTimeField does not
> attach a timezone to the datetime objects it pulls out of the DB, but
> some (most? all?) parts of pulp expect to compare datetimes that DO have
> a timezone. I've already seen the same error show up in additional
> places, particularly in plugins.
> Of course all datetimes stored in the DB are supposed to be in UTC.
> We could create a UTCDateTimeField that just overrides the to_python()
> method and calls the above-referenced ensure_tz() function on the value.
> Without doing much digging, it seems like this would be the quickest
> path to consistency. The other option is to standardize on NOT having
> timezones on datetime objects, and assuming UTC. That seems marginally
> riskier, but not greatly so. It would probably require more work.
> Continuing to sprinkle calls to ensure_tz() all over the code base seems
> like a messy way to address the issue.
> Thoughts? Perhaps those who have been heavily involved in the
> mongoengine conversion already have considered this.
> Pulp-list mailing list
> Pulp-list at redhat.com
More information about the Pulp-list