On Saturday 19 December 2015 11:23:17 Erik Cederstrand wrote: > > Den 19. dec. 2015 kl. 16.01 skrev Aymeric Augustin > > <aymeric.augus...@polytechnique.org>: > > > > To be fair, this has a lot to do with MySQL’s lax approach to storing > > data. There’s so many situations where it just throws data away happily > > that one can’t really expect to read back data written to MySQL. > > > > That said, this change in Django sets up this trap for unsuspecting > > users. Providing a way for users to declare which fields use the old > > format won't work because of pluggable apps: they cannot know what > > version of MySQL their users were running when they first created a > > given datetime column. The best solution may be to provide a conversion > > script to upgrade all datetime columns from the old to the new format. > > One simple solution could be for Christiano to subclass the DateTimeField > to handle the microsecond precision explicitly. Something like this to > strip: > > > class DateTimeFieldWithPrecision(DateTimeField): > def __init__(self, *args, **kwargs): > self.precision = kwargs.get('precision', 6) > assert 0 <= self.precision <= 6 > super().__init__(*args, **kwargs) > > def pre_save(self, model_instance, add): > dt = getattr(model_instance, self.attname) > dt.replace(microsecond=int(dt.microsecond/10**(6-self.precision))) > return dt >
if I get the complaints correctly, something similar would need to be done when preparing a value for querying. More generally, I think Christiano just wants "the old field back" -- so, he has a use-case for a DateTimeField which explicitly does not use second fractions. We already have a DateTimeField which explicitly does not use day fractions (DateField), so I suppose we could find sense in that... We would typically suggest, as Erik implicitly did, that such field be done outside of Django, but the backward-compatibility issues mentioned by Aymeric make it quite plausible that such a field will be added to core or contrib. Shai.