timestamp out of range for platform time_t

[s.vallosio@…]

Hi, i have updated the wiki to version 0.11.7 but I get the following problem:

Trac detected an internal error:

ValueError: timestamp out of range for platform time_t

This is the Python Traceback:
File "/usr/lib/python2.4/site-packages/Trac-0.11.7-py2.4.egg/trac/web/main.py", line 450, in _dispatch_request
  dispatcher.dispatch(req)
File "/usr/lib/python2.4/site-packages/Trac-0.11.7-py2.4.egg/trac/web/main.py", line 206, in dispatch
  resp = chosen_handler.process_request(req)
File "/usr/lib/python2.4/site-packages/Trac-0.11.7-py2.4.egg/trac/wiki/web_ui.py", line 118, in process_request
  page = WikiPage(self.env, pagename)
File "/usr/lib/python2.4/site-packages/Trac-0.11.7-py2.4.egg/trac/wiki/model.py", line 43, in __init__
  self._fetch(name, version, db)
File "/usr/lib/python2.4/site-packages/Trac-0.11.7-py2.4.egg/trac/wiki/model.py", line 70, in _fetch
  self.time = datetime.fromtimestamp(time, utc)

This is the System Information:

Trac: 0.11.7 
Python: 2.4.2 (#2, Sep 30 2005, 21:23:58) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] 
setuptools: 0.6c9 
SQLite: 3.2.1 
pysqlite: 2.0.3 
Genshi: 0.6 
mod_python: < 3.2 
Subversion: 1.2.0 (r14790) 
jQuery: 1.2.6 

Can you help me, please!?

[Christian Boos]

Are you sure it was an upgrade and not a downgrade from trunk?

Does it happen for all pages?

For the page it happens, what's in the db?

$ echo "select * from wiki where name='WikiStart' and version=(select max(version) from wiki where name='WikiStart');" \
    | sqlite3 your_tracenv/db/trac.db 

[s.vallosio@…]

Yes, i'll be sure it is a upgrade. I have downloaded the last version from the site. The problem it is only for the Wiki start page, but for all my projects. For example, for the first project, the result of the query is:

WikiStart|12|1258387758164372|vdagna|85.34.172.233|== Gestione Sala Macchine Str
adale Torino ==


Creare ("'''New Ticket'''") e consultare i Ticket per documentare i lavori fatti
 nella nostra sala macchine di Stradale Torino.

Gli "attributi" milestone e version non sono utilizzati (valore fisso). L'attrib
uto "component" è significativo.

Attualmente in "'''View Ticket'''" sono stati sistemati 2 report, quelli che ini
ziano con ">>"

Utilizzare anche "'''Search'''" che permette di cercare nel titolo, nella descri
zione e nelle keyword di ciascun Ticket

"'''Browse Source'''" permette di vedere i file gestiti tramite Tortoise (elenco
 server, etc.)

 1. [wiki:W2003 W2003-Camperonline]

 2. [wiki:asfapsrv ASF:asf-as]

 3. [wiki:ltnapsrv ASF:Leitner-as]

 4. [wiki:Apache 238: Apache - 238]

 4. [wiki:SigemiApp214: SigemiApp - 214]

 5. Documentazione Server Farm: [http://wiki.netsurf.it/svn/documentazioneNS Lin
k esterno] - [http://10.110.52.247/svn/documentazioneNS Link interno]
||0

Thanks …

[Christian Boos]

([OT] you really need to have a quick look at WikiFormatting ;-) )

[Christian Boos]

(me too ;-) )

[Christian Boos]

Ok, so 1258387758164372 is really too big for the modified date timestamp.

>>> datetime.datetime.fromtimestamp(1258387758164372)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: timestamp out of range for platform localtime()/gmtime() function

Now, it would be interesting to understand how this value got there. It really looks like a 0.12 timestamp (microseconds since epoch), as:

>>> datetime.datetime.fromtimestamp(1258387758164372/1000000)
datetime.datetime(2009, 11, 16, 17, 9, 18)

Did you ever access that database using trunk or 0.12b1? Are you using any plugin?

What's the output of:

select value from system where name='database_version';

[Remy Blank]

This definitely looks like a microsecond timestamp, which is certainly not available in 0.11-stable. What do you get with the following:

$ echo "select version, time from wiki where name='WikiStart';" \
    | sqlite3 your_tracenv/db/trac.db 

[Christian Boos]

I think we should add a check in 0.11-stable preventing Trac to run when the database_version is higher than expected. This used to work for some time, but not any longer, so better abort in such cases.

[s.vallosio@…]

cboos the 'database_version' is 21

rbank the results of a select is :
1|1251195610000000
2|1251196421522408
3|1251217504371600
4|1251217560209661
5|1251217762832468
6|1251273524696344
7|1253111813336776
8|1254398808592468
9|1255097149198802
10|1255097204100551
11|1255524940880317
12|1258387758164372

[Remy Blank]

This definitely looks like the database was upgraded, then downgraded "by hand".

Or no, rather it was used for some time with trunk, then downgraded. Otherwise we would have lots of trailing 0s.

[Christian Boos]

Was a local InstallationIssue (i.e. for downgrading, you're on your own).

[mg.ryder@…]

I have just found this issue and can comment on how it occurs. It was installed in Ubuntu 10.04 and I upgraded to trac 0.12 Recently I upgraded to Ubuntu 11.04 It would seem that Ubuntu 11.04 has trac 0.11 and regressed my installation Re-running "sudo easy_install —upgrade Trac==0.12" fixed it for me.

[szybalski@…]

Hello, Thanks for the details here. We actually upgraded our test which pointed to production data. This TT helped quickly figure out what happened.

Fix: Need to upgrade production to 0.12 now :)

Thanks Lucas