Open masipcat opened 4 years ago
I guess we could fallback if it was not parsable by the faster parsers.
I would be worried about removing parsing capability though.
Is it worth it if we have fallbacks?
I guess it depends on which formats we expect to support.
Pendulum
, by default (strict=True
), supports the RFC 3339 format, most ISO 8601 formats and some other common formats (according to their doc https://pendulum.eustace.io/docs/#parsing).
Examples:
In case we want to support other formats too, we can just set strict=False
and in that case pendulum
calls dateutil.parse
as a fallback (https://github.com/sdispater/pendulum/blob/c99f24215faf1fca544858a7a1ec6ff3538aa34f/pendulum/parsing/__init__.py#L107-L137).
PS: I reimplemented the IDatetime
deserializer in our application to fit our needs (for a different thing) but we are ok only supporting RFC 3339/ ISO 8601. That's why I'm asking which dates formats we expect and if it's interesting to have it in Guillotina or not :)
Okay, it seems to me that strict=False
is the best option.
I think the design was meant to allow guillotina to be permissive and provide good parsing support for generic formats. I don't actually like that because I think dates should follow common iso formatting rules; however, I imagine we'll break people if we remove it.
Also, if you want we can do pendulum
optional. If it's installed we use Pendulum parser's with strict=False
. Otherwise, we use dateutil.parse as it is now. Sound good?
sounds great!
Hi,
I'm opening this issue to ask you what's the expected format of datetimes. https://github.com/plone/guillotina/blob/c2aba28395f8399680ec0b0ea84de05e94d972de/guillotina/json/deserialize_value.py#L164-L168
If we only expect ISO-8601 I think we could consider using
dateutil.parser.isoparse
.Simple benchmark (python 3.8):
Also, we could consider using
pendulum
parser (this function returns<class 'datetime.datetime'>
!):What do you think?