Add load_as_tz_aware (and dump_as_tz_aware ?) parameter to DateTime
See original GitHub issueAs said in the docs,
Schema.load returns datetime objects that are timezone-aware.
I’m using webargs to parse input to an API and the code expects naive datetime
s. I would like to get naive datetime
s, rather than having to remove the TZ from every date attribute in each resource method.
Maybe I’m wrong working with naive datetime
s in the first place. I have no opinion about it. But sometimes you’re working with a lib that expects naive datetime
s, and you don’t want to patch it.
I guess the most flexible approach would be to provide a field parameter allowing to choose which format a DateTime
field should output.
Could it be possible to have this configured with a flag/metadata in the DateTime
field?
Or is there a design reason not to allow this?
(Apparently, I’m not the first one falling into this: https://github.com/marshmallow-code/marshmallow/issues/309.)
Issue Analytics
- State:
- Created 7 years ago
- Comments:9 (9 by maintainers)
I ended up subclassing
DateTime
in a customField
with aload_as_tz_aware
boolean parameter. (Discussion here.)Basically, it deserializes like this:
I still think this could be addressed in Marshmallow.
Using Marshmallow + webargs to parse API inputs is a typical use case, and currently, you can’t rely on it to ensure the awareness of deserialized dates. This is an issue, especially since comparisons of aware and non-aware dates generate an exception: a user can make the application crash by providing wrong input data. Unless of course the application has specific code to cope with both formats, or ensures awareness by itself, but isn’t this Marshmallow’s purpose?
My subclass only addresses deserialization, but there may also be a use case for a
dump_as_tz_aware
parameter (which I think is a bit harder to do in a subclass).Closing in favor of https://github.com/marshmallow-code/marshmallow/issues/1234.