ValueError: year=1899 is before 1900; the datetime strftime() methods require year >= 1900

[Ryan J Ollos]

Maybe we can raise a TracError for this case, or add/or a warning to the timeline page.

2016-05-26 14:42:07,161 Trac[main] ERROR: Internal Server Error: <RequestWithSession "GET '/timeline?from=1900-01-02&daysback=7&authors='">, referrer 'https://bugs.jqueryui.com/'
Traceback (most recent call last):
  File "/var/www/bugs.jqueryui.com/private/pve/local/lib/python2.7/site-packages/trac/web/main.py", line 562, in _dispatch_request
    dispatcher.dispatch(req)
  File "/var/www/bugs.jqueryui.com/private/pve/local/lib/python2.7/site-packages/trac/web/main.py", line 249, in dispatch
    resp = chosen_handler.process_request(req)
  File "/var/www/bugs.jqueryui.com/private/pve/local/lib/python2.7/site-packages/trac/timeline/web_ui.py", line 251, in process_request
    format='%Y-%m-%d', tzinfo=req.tz)
  File "/var/www/bugs.jqueryui.com/private/pve/local/lib/python2.7/site-packages/trac/util/datefmt.py", line 318, in format_date
    return _format_datetime(t, format, tzinfo, locale, 'date')
  File "/var/www/bugs.jqueryui.com/private/pve/local/lib/python2.7/site-packages/trac/util/datefmt.py", line 299, in _format_datetime
    return _format_datetime_without_babel(t, format)
  File "/var/www/bugs.jqueryui.com/private/pve/local/lib/python2.7/site-packages/trac/util/datefmt.py", line 246, in _format_datetime_without_babel
    text = t.strftime(str(format))
ValueError: year=1899 is before 1900; the datetime strftime() methods require year >= 1900

[Ryan J Ollos]

Proposed changes in log:rjollos.git:t12489_year_1899.

[Jun Omae]

I don't agree [3e45f669/rjollos.git] because the change would lead unexpected result if across DST boundary.

[Jun Omae]

We could simply use 'iso8601' format to solve the original issue.

trac/timeline/web_ui.py

@@ -248 +248 @@
         previous_start = fromdate.replace(tzinfo=None) - \
                          timedelta(days=daysback + 1)
         previous_start = format_date(to_datetime(previous_start, req.tz),
-                                     format='%Y-%m-%d', tzinfo=req.tz)
+                                     format='iso8601', tzinfo=req.tz)
         add_link(req, 'prev', req.href.timeline(from_=previous_start,
                                                 authors=authors,
                                                 daysback=daysback),
@@ -257 +257 @@
             next_start = fromdate.replace(tzinfo=None) + \
                          timedelta(days=daysback + 1)
             next_start = format_date(to_datetime(next_start, req.tz),
-                                     format='%Y-%m-%d', tzinfo=req.tz)
+                                     format='iso8601', tzinfo=req.tz)
             add_link(req, 'next', req.href.timeline(from_=next_start,
                                                     authors=authors,
                                                     daysback=daysback),

[Ryan J Ollos]

Replying to Jun Omae:

I don't agree [3e45f669/rjollos.git] because the change would lead unexpected result if across DST boundary.

I noticed that the naive datetime object is immediately converted to a tz-aware datetime object in _format_datetime​, which is called by format_date​. Therefore to_datetime(next_start, req.tz) in trac.timeline.web_ui appears to be redundant.

[Ryan J Ollos]

Yeah, comment:3 is the simpler solution. Committed to 1.0-stable in [14810], merged to trunk in [14811]. Added test in [14816], merged to trunk in [14817:14818].

[Jun Omae]

Replying to Ryan J Ollos:

Replying to Jun Omae:

I don't agree [3e45f669/rjollos.git] because the change would lead unexpected result if across DST boundary.

I noticed that the naive datetime object is immediately converted to a tz-aware datetime object in _format_datetime​, which is called by format_date​. Therefore to_datetime(next_start, req.tz) in trac.timeline.web_ui appears to be redundant.

Ok. You're right. I've misunderstood. Please apply it.

[Ryan J Ollos]

Thanks. The minor change was committed in [14821], merged in [14822].