Paul G added the comment:
This seems very useful to me. I very frequently advise people *against* using
dateutil.parser (despite my conflict of interest as maintainer of dateutil) for
well-known formats, but the problem frequently comes up of, "what should I do
when I have date creat
Paul G added the comment:
@r.david.murray In the other thread, you mention that the full test suite is
run against the C and Python implementations, so that answers the question of
how to write the tests.
I think treating it as an enhancement in Python 3.7 makes a reasonable amount
of sense
New submission from Paul G:
In the .py implementation of datetime.replace (and date.replace and
time.replace), the new datetime is created using the datetime type:
https://github.com/python/cpython/blob/master/Lib/datetime.py#L1578
But in the C source, it is created from type(self):
https
Paul G added the comment:
I've never written a "What's New" before, but here are the main things I took
away from implementing a PEP 495-compliant tzinfo class:
- The `fold` attribute is the SECOND occurrence of the time, not the first
occurrence of the time. In my first p
Paul G added the comment:
> After all, how much effort would it save for you in dateutil if you could
> reuse the base class fromutc?
Realistically, this saves me nothing since I have to re-implement it anyway in
in all versions <= Python 3.6 (basically just the exact same algor
Paul G added the comment:
Of the `tzinfo` implementations provided by `python-dateutil`, `tzrange`,
`tzstr` (GNU TZ strings), `tzwin` (Windows style time zones) and `tzlocal` all
satisfy this condition. These are basically all implementations of default
system time zone information.
With
New submission from Paul G:
After PEP-495, the default value for non-fold-aware datetimes is that they
return the DST side, not the STD side (as was the assumption before PEP-495).
This invalidates an assumption made in `tz.fromutc()`. See lines 991-1000 of
datetime.py:
dtdst = dt.dst
New submission from Paul G:
According to PEP495
(https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison)
datetimes are considered not equal if they are an ambiguous time and have
different zones. However, currently "interzone comparison" is defined /
implemen
