[issue26460] datetime.strptime without a year fails on Feb 29

2020-03-03 Thread Nick Moore
Nick Moore added the comment: It's kind of funny that there's already consideration of this in _strptime._strptime(), which returns a tuple used by datetime.datetime.strptime() to construct the new datetime. Search for `leap_year_fix`. I think the concern though is if we changed the default

[issue26460] datetime.strptime without a year fails on Feb 29

2020-03-03 Thread Gerard C Weatherby
Gerard C Weatherby added the comment: Yes, code that has been working for my organization the past two years just broke this weekend. Meaning depends on context. The straightforward solution is that if no year is specified, the return value should default to the current year. --

[issue26460] datetime.strptime without a year fails on Feb 29

2020-03-02 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: > On Mar 2, 2020, at 6:33 PM, Gregory P. Smith wrote: > > Change that default to any old year with a leap year (1904?) In the 21st century, the year 2000 default makes much more sense than 1900. Luckily 2000 is also a leap year. --

[issue26460] datetime.strptime without a year fails on Feb 29

2020-03-02 Thread Gregory P. Smith
Gregory P. Smith added the comment: I _doubt_ there is code expecting the default year when unspecified to actually be 1900. Change that default to any old year with a leap year (1904?) and it'll still (a) stand out as a special year that can be looked up should it wind up being _used_ as

[issue26460] datetime.strptime without a year fails on Feb 29

2020-03-02 Thread Nick Moore
Nick Moore added the comment: Not disagreeing with you that "%b %d" timestamps with no "%Y" are excerable, but they're fairly common in the *nix world unfortunately. People need to parse them, and the simple and obvious way to do this breaks every four years. I like the idea of having a

[issue26460] datetime.strptime without a year fails on Feb 29

2020-03-02 Thread Paul Ganssle
Paul Ganssle added the comment: I don't think adding a default_year parameter is the right solution here. The actual problem is that `time.strptime`, and by extension `datetime.strptime` has a strange and confusing interface. What should happen is either that `year` is set to None or some

[issue26460] datetime.strptime without a year fails on Feb 29

2020-03-01 Thread Nick Moore
Nick Moore added the comment: I suspect this is going to come up about this time of every leap year :-/ The workaround is prepending "%Y " to the pattern and eg: "2020 " to the date string, but that's not very nice. Would adding a kwarg "default_year" be an acceptable solution? I can't

[issue26460] datetime.strptime without a year fails on Feb 29

2019-05-21 Thread Karthikeyan Singaravelan
Karthikeyan Singaravelan added the comment: See also issue19376. This behavior is now documented with https://github.com/python/cpython/commit/56027ccd6b9dab4a090e4fef8574933fb9a36ff2 -- nosy: +xtreak ___ Python tracker

[issue26460] datetime.strptime without a year fails on Feb 29

2016-03-02 Thread Andrej Antonov
Changes by Andrej Antonov : -- nosy: +polymorphm ___ Python tracker ___ ___

[issue26460] datetime.strptime without a year fails on Feb 29

2016-02-29 Thread Gregory P. Smith
Gregory P. Smith added the comment: time.strptime() is "working" (not raising an exception) as it appears not to validate the day of the month when a year is not specified, yet the return value from either of these APIs is a date which has no concept of an ambiguous year. ## Via the

[issue26460] datetime.strptime without a year fails on Feb 29

2016-02-29 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: > Python's time.strptime() behavior is consistent with that of glibc 2.19 Gregory, I believe OP is complaining about the way datetime.datetime.strptime() behaves, not time.strptime() which is mentioned as (preferred?) alternative. See msg261015 in

[issue26460] datetime.strptime without a year fails on Feb 29

2016-02-29 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: This is not no more bug than >>> from datetime import * >>> datetime.strptime('0228', '%m%d') datetime.datetime(1900, 2, 28, 0, 0) Naturally, as long as datetime.strptime('0228', '%m%d') is the same as datetime.strptime('19000228', '%Y%m%d'),

[issue26460] datetime.strptime without a year fails on Feb 29

2016-02-29 Thread Gregory P. Smith
Gregory P. Smith added the comment: Python's time.strptime() behavior is consistent with that of glibc 2.19: === strptime_c.c === #define _XOPEN_SOURCE #include #include #include #include int main(void) { struct tm tm; char buf[255]; memset(, 0, sizeof(struct tm));

[issue26460] datetime.strptime without a year fails on Feb 29

2016-02-29 Thread Sriram Rajagopalan
New submission from Sriram Rajagopalan: $ python Python 3.5.1 (default, Dec 7 2015, 12:58:09) [GCC 5.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> >>> >>> >>> import time >>> >>> time.strptime("Feb 29", "%b %d")