[Alexander Walters]
>> 1. no one will expect the datetime module is_dst to map to the posix mktime
>> function.
[Alexander Belopolsky]
> Please don't overgeneralize. The fact that *I* would expect "is_dst"
> in local to UTC converstion to act as the familiar "tm_isdst" does
> in local to "seconds since 1970-01-01T00:00 UTC"
> conversion is enough to invalidate your claim about "no one". I also
> suspect I am not alone.
You're far from alone, but there's no need to argue the point: you
already won ;-) That is, Guido already Pronounced on this:
https://mail.python.org/pipermail/datetime-sig/2015-July/000094.html
...
The road to improvement that I encourage everyone to explore: add an is_dst
flag (with a different name)
...
And you've already explained why at length: the intended meaning of
tm_isdst is baffling in some cases, so we do want different semantics,
but because CPython is intended to work nicely with C code written by
C programmers it's always a mistake to use similar names in similar
contexts when the semantics differ in fundamental ways. "first" is a
good solution: not confusable with any familiar name in C's view of
time, and its meaning is both sensible and utterly clear in all
ambiguous cases.
At least until the next C standard adds tm_first to mean "equal to
tm_isdst except in rare cases of double (or greater) leap seconds, in
which case the value is as specified by the Finely Interpolated Real
Second Time (FIRST) standard" ;--)
_______________________________________________
Datetime-SIG mailing list
[email protected]
https://mail.python.org/mailman/listinfo/datetime-sig
The PSF Code of Conduct applies to this mailing list:
https://www.python.org/psf/codeofconduct/
