kakulukia
commented
6 years ago Okay, @sdispater there should be a clear warning in the docs to NOT USE this library WITH SQLite, since this was causing all the headaches. Though it claims to be able to handle both the T and space separator, it actually aint working that well. Switching to Postgres i dont have any trouble any longer.
Only after i discovered the root of all evil, i noticed you have a limitations section, but sadly this is not linked in the documentation menu and i would also advise to at least put a small link and hint into the installation section. Adding the known workarounds for your database kinda belongs to installing.
And please put another hint in there and recommend to use Postgres.
I also noticed there is a custom DateTimeField - nice! Why not make it an official feature, which also returns pendulum instances rather than the default datetimes. Id love that. I might also contribute that, but this might take some more time. Please give me a hint of where to put that field definition. What about pendulum.utils.fields?
I just started my first Django project where i wanted to fully use pendulum as the base datetime lib, but i already hit my first mayor problem, that is a real showstopper.
When saving datetimes, pendulums string representation will be stored in the DB. While the DB in my case SQLite and Postgres accepts those values and has no problems with em, some Django functions around datetimes do have a problem with en.
For example the datetime filter in the admin makes use of the dates() feature of querysets, which is broken with pendulums datetimes.
I built a little test project at https://github.com/kakulukia/pendulumtest - the Readme tells you how to run the tests.
The weirdest thing tho: When saved with datetime.datetime i cant query with a pendulum.datetime and even weirder the pendulum datetime gets interpreted as being 23h in advance.
Obviously Django is doing something wrong, since running plain SQL against the DB, its the same with or without a T in between date and time.
But before filing a bug for Django id like to understand why pendulum has another representation than datatime.datetime? Are there any advantages? So far i only see the disadvantage of breaking the ORM of a mayor Python framework. https://www.jetbrains.com/research/python-developers-survey-2017/#technologies
I also noticed there are a lot of to_xxx_string methods, but none of them resemble the string output of datetime.datetime. Why? Is the python datetime violation RFC/ISO standards? Or did i just miss the datetime string method? I know there is a to_datetime_string. But this is just date and time without TZ.
Sure, i could go back to using relativedelta and datetime again, but id like to understand, why pendulum does things the way its does them first. At he end maybe Django really is broken .. but id like to have some arguments at hand before going into a discussion. :)