Add load_as_tz_aware (and dump_as_tz_aware ?) parameter to DateTime

As 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 datetimes. I would like to get naive datetimes, rather than having to remove the TZ from every date attribute in each resource method.

Maybe I’m wrong working with naive datetimes in the first place. I have no opinion about it. But sometimes you’re working with a lib that expects naive datetimes, 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.)

[lafrech]

I ended up subclassing DateTime in a custom Field with a load_as_tz_aware boolean parameter. (Discussion here.)

Basically, it deserializes like this:

        date = super()._deserialize(value, attr, data)
        if self.load_as_tz_aware:
            # If datetime is TZ naive, set UTC timezone
            if date.tzinfo is None or date.tzinfo.utcoffset(date) is None:
                date = date.replace(tzinfo=tzutc())
        else:
            # If datetime is TZ aware, convert it to UTC and remove TZ info
            if date.tzinfo is not None and date.tzinfo.utcoffset(date) is not None:
                date = date.astimezone(tzutc())
            date = date.replace(tzinfo=None)
        return date

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).

[lafrech]

Closing in favor of https://github.com/marshmallow-code/marshmallow/issues/1234.