Error when pushing data to Heroku: time zone displ

Question

I run the following command to push the contents of my local database to Heroku:

heroku db:push --app my-app

From my home computer this works flawlessly but from my work computer I get this error:

Taps Server Error: PGError: ERROR: time zone displacement out of range: "2011-11-15 12:00:00.000000+5894114400"

I'm not sure where that date is coming from, I can't find it in the data anywhere. Any ideas what's going on and/or how to fix it?

Answer 1

Just changing the ruby version has not worked for me. Instead I've narrowed down the issue to the new Heroku Toolbelt.

When using the older heroku gem I'm able to db:push just fine. Until heroku fixes it i've created a new gemset and installed the heroku gem. I just switch to this gemset whenever I need to do a db:push.

Answer 2

Try to use native taps without heroku db:push.

taps server POSTGRES_DATABASE_REMOTE_URL login pass

taps push sqlite://db/development.sqlite3 login:pass@localhost:5000

solved the problem for me

Answer 3

I run 1.9.3p125 on Heroku and 1.9.3p125 on my local machine. If I want to db:push I just switch to 1.9.2 while uploading:

rvm use ruby-1.9.2-p290
heroku db:push --app my-app
rvm use ruby-1.9.3-p125

Then once the push is complete, I switch back to 1.9.3.

Answer 4

It didn't work for me either using 1.9.3 or 1.9.2.

As Pablo pointed out the problem has to do with the marshalling of the dates (the marshalling converts the date to 12:00:00+XXXX" despite my date type was 'timestamp without timezone').

Anyway, I worked it around by setting the dates to null, so I could successfully push to Heroku. Very poor solution, though. I hope the bug will get fixed soon.

Answer 5

Which Heroku stack are you on? If you are on bamboo-ree-1.8.7 the right version to use is 1.8.7. This is a marshalling problem and can be solved by using the same Ruby version on both the server and the client.

Answer 6

It helped me to solve my problem, very practical https://github.com/ricardochimal/taps/issues/92#issuecomment-11996909