Modify

Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#7355 closed defect (fixed)

timestamp out of range for platform time_t error with Trac 0.12 (suggested patch is now attached)

Reported by: eric.portelance@… Owned by: hoessler
Priority: normal Component: EstimationToolsPlugin
Severity: normal Keywords:
Cc: scottj@… Trac Release: 0.12

Description

After installing Trac 0.12 we are getting a "timestamp out of range for platform time_t" error.

Attachments (2)

datefmt.diff (1.9 KB) - added by bjorn@… 4 years ago.
use new date format conversion method as req 0.12+
t7355-to_utimestamp_compat-r5360.diff (2.3 KB) - added by osimons 4 years ago.
Updated patch that should support both 0.11 and 0.12.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 4 years ago by osimons

Traceback, please. Use Trac debug logging to get the full error from the server. Anything else needed to reproduce this (like macro or macro options)?

Changed 4 years ago by bjorn@…

use new date format conversion method as req 0.12+

comment:2 Changed 4 years ago by bjorn

I think he is hitting a bug that I think I have fixed in attached patch. The problem is that 0.12 uses new timestamp format:

http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.12#Timestampstorageindatabase

Not sure if I've messed up UTM zone consideration though.

comment:3 Changed 4 years ago by anonymous

  • Summary changed from timestamp out of range for platform time_t error with Trac 0.12 to timestamp out of range for platform time_t error with Trac 0.12 (suggested patch is now attached)

Changed 4 years ago by osimons

Updated patch that should support both 0.11 and 0.12.

comment:4 Changed 4 years ago by osimons

Thanks for the patch. I've updated it, and made it work across Trac versions to avoid branching just for this. Please try attachment:t7355-to_utimestamp_compat-r5360.diff

Untested on 0.12 by me, so please report back after testing.

comment:5 Changed 4 years ago by hoessler

  • Status changed from new to assigned

If someone could verify that it works on 0.12, I will apply osimons patch on trunk.

comment:6 Changed 4 years ago by bjornharrtell

Verified as working on 0.12, nice work making it compatible.

comment:7 Changed 4 years ago by hoessler

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [8296]) applied patch by bjorn@… and osimons to support trac 0.12. Fixes #7355.

comment:8 Changed 4 years ago by scottj@…

I'm still getting this error with BurndownChart, after pulling from trunk and building r9029. Do I need to do anything special to reconfigure the plugin after installation?

comment:9 Changed 4 years ago by anonymous

  • Cc scottj@… added; anonymous removed

comment:10 follow-up: Changed 3 years ago by anonymous

fast fix:

echo "update wiki set time= substr(time, 0, length(time)-6);" | sqlite3 /var/trac/db/trac.db

comment:11 in reply to: ↑ 10 Changed 3 years ago by osimons

Replying to anonymous:

fast fix:

echo "update wiki set time= substr(time, 0, length(time)-6);" | sqlite3 /var/trac/db/trac.db

This is not a fast fix for anything. It is a super-fast way of making your Trac 0.12+ wiki think it is ~42 years back in time... Don't run it!

Speaking of, how can changing timestamps in wiki table ever affect the ticket timestamps that the EstimationToolsPlugin uses to render ticket graphs and stats???

Add Comment

Modify Ticket

Action
as closed The owner will remain hoessler.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.