Opened 14 years ago
Closed 14 years ago
#9598 closed defect (invalid)
All ticket times show up as 41 years ago
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | general | Version: | 0.12-stable |
| Severity: | critical | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
I just upgraded trac from 0.11.4 to 0.12 and now all dates on tickets are from 41 years ago. We are using MySQL as the backend, and looking at the ticket and ticket_changes tables, all of the time fields are full and correct.
But all times show up as 1969-12-31T17:21:23-07:00. When I try and comment on a ticket, it sets the time in the db for that change as 2147483647.
I assume this is some how a bug in my system, and not a bug in the trac upgrader, but I can't figure it out for the life of me.
Also i'm on python 2.4 and running this through apache2.
Attachments (0)
Change History (3)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
I did, but while the fields are big int, they are definitly the former size, not the latter.
I guess I should run a query to multiply all of the time fields by 1000000?
comment:3 by , 14 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
I went through and corrected all of the fields by restoring to the db dump I made before hand and redoing the db upgrade. That seemed to fix the issue. Not sure why the values didn't get changed the first time. Thanks for pointing me in the right direction rblank.
Replying to nat@…:
If that's the case, this issue doesn't belong here. But…
… this is very suspect. Are you sure the time fields are correct? Do they rather look like
1283408980or like1283408980000000? It should be the latter.It looks like the timestamps weren't converted to microseconds, and the timestamp columns weren't converted to
BIGINT. Could you please check the type of the time fields? I assume you rantrac-admin $ENV upgradeand you didn't get any error messages?