Closed Bug 1046213 Opened 5 years ago Closed 5 years ago

datetime_from() generates wrong dates if year < 1901

Categories

(Bugzilla :: Bugzilla-General, defect, minor)

4.5.5
defect
Not set
minor

Tracking

()

RESOLVED FIXED
Bugzilla 4.4

People

(Reporter: LpSolit, Assigned: LpSolit)

Details

Attachments

(1 file)

Attached patch patch, v1Splinter Review
While investigating why datetime_from("1900-12-31") takes 5.74 seconds on my machine and datetime_from("1901-01-01") takes 0.10 second, I realized that datetime_from() was passing incorrect data to DateTime->new() if the date was older than 1901 (which can happen as we have date and datetime custom fields). That's because strptime() returns the full year if older than 1901. So datetime_from() was incorrectly converting year 1900 into year 3800, making DateTime() terribly slow.
Attachment #8464767 - Flags: review?(sgreen)
Given that Date::Parse (which uses Date::Local) is known to be buggy (see https://metacpan.org/pod/Date::Parse#LIMITATION), wouldn't a better solution to be using something like DateTime::Format::Strptime ( https://metacpan.org/pod/DateTime::Format::Strptime ), especially considering we turn it into a DateTime object anyway?
Flags: needinfo?(LpSolit)
(In reply to sgreen from comment #1)

That's an idea, but the problem is that DateTime::Format::Strptime::new() requires the pattern to be provided, i.e. you must know which format is used for the input datetime string, while Date::Parse::strptime() runs several regexps to guess which format is used. As datetime_from() is called from many places, it's hard to determine the pattern for sure, unless we run our own regexps first.
Flags: needinfo?(LpSolit)
Attachment #8464767 - Flags: review?(sgreen) → review+
Flags: approval?
Flags: approval4.4?
Flags: approval?
Flags: approval4.4?
Flags: approval4.4+
Flags: approval+
To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   ace2e1a..fc4350a  master -> master

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   e74616b..76b3203  4.4 -> 4.4
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.