heroku db:push Time Zone Issue #92

trvrplk opened this Issue Nov 11, 2011 · 76 comments


None yet

trvrplk commented Nov 11, 2011

When I run heroku db:push, it works fine until it saves the seesion, the says someting like:

!  Caught Server Exeption

HTTP Code: 500

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

and then a bunch of gibberish in a sort of array. How do I get heroku db:push to work and fix the error?

I've currently got the same issue pushing a sqlite3 db up to heroku. Its the first push i've done with this project, it is a clean rails 3.1.1 app with just a couple models.

I tried changing timezones and restarting the terminal, but doesn't seem to have changed anything.

Saving session to push_201111141334.dat..
!!! Caught Server Exception
Taps Server Error: PGError: ERROR:  time zone displacement out of range: "2011-11-14 12:00:00.000000+5894112000"

["/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:175:in `async_exec'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:175:in `block (2 levels) in execute'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/logging.rb:28:in `log_yield'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:175:in `block in execute'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:158:in `check_disconnect_errors'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:175:in `execute'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:240:in `block (2 levels) in execute'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/connection_pool/threaded.rb:71:in `hold'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/connecting.rb:226:in `synchronize'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:240:in `block in execute'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:261:in `check_database_errors'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:238:in `execute'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/query.rb:71:in `execute_dui'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:552:in `execute_dui'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:243:in `block (2 levels) in import'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:243:in `each'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:243:in `block in import'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/query.rb:223:in `_transaction'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/query.rb:209:in `block in transaction'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/connection_pool/threaded.rb:84:in `hold'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/connecting.rb:226:in `synchronize'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/query.rb:207:in `transaction'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:243:in `import'", 
"/app/lib/taps/data_stream.rb:315:in `import_rows'", "/app/lib/taps/data_stream.rb:158:in `fetch_remote_in_server'", 
"/app/lib/taps/server.rb:94:in `block (3 levels) in <class:Server>'", "/app/lib/taps/utils.rb:161:in `call'", 
"/app/lib/taps/utils.rb:161:in `server_error_handling'", "/app/lib/taps/server.rb:92:in `block (2 levels) in <class:Server>'", 
"/app/lib/taps/db_session.rb:15:in `block in conn'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-
3.20.0/lib/sequel/database/connecting.rb:76:in `connect'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-
3.20.0/lib/sequel/core.rb:119:in `connect'", "/app/lib/taps/db_session.rb:14:in `conn'", "/app/lib/taps/server.rb:91:in `block in 
<class:Server>'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:865:in `call'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:865:in `block in route'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:521:in `instance_eval'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:521:in `route_eval'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:500:in `block (2 levels) in route!'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:497:in `catch'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:497:in `block in route!'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:476:in `each'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:476:in `route!'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:601:in `dispatch!'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:411:in `block in call!'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `instance_eval'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `block in invoke'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `catch'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `invoke'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:411:in `call!'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:399:in `call'", "/app/.bundle/gems/ruby/1.9.1/gems/rack-
1.2.1/lib/rack/auth/basic.rb:25:in `call'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:979:in `block in 
call'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:1005:in `synchronize'", 
"/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:979:in `call'",             
"/home/heroku_rack/lib/static_assets.rb:9:in `call'", "/home/heroku_rack/lib/last_access.rb:15:in `call'",
1.2.1/lib/rack/urlmap.rb:47:in `block in call'", "/app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.1/lib/rack/urlmap.rb:41:in 
"/app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.1/lib/rack/urlmap.rb:41:in `call'", "/home/heroku_rack/lib/date_header.rb:14:in 
`call'", "/app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.1/lib/rack/builder.rb:77:in `call'", 
"/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/connection.rb:76:in `block in pre_process'", 
"/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/connection.rb:74:in `catch'",  
1.2.7/lib/thin/connection.rb:74:in `pre_process'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/connection.rb:57:in  
`process'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/connection.rb:42:in `receive_data'", 
"/app/.bundle/gems/ruby/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'", 
"/app/.bundle/gems/ruby/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'", 
"/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/backends/base.rb:57:in `start'", 
"/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/server.rb:156:in `start'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-
1.2.7/lib/thin/controllers/controller.rb:80:in `start'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/runner.rb:177:in 
`run_command'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/runner.rb:143:in `run!'", 
"/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/bin/thin:6:in `<top (required)>'", "/usr/ruby1.9.2/bin/thin:19:in `load'", 
"/usr/ruby1.9.2/bin/thin:19:in `<main>'"]

I have the same issue. Rails 3.1.1, sqlite3, ruby 1.9.3p0

Saving session to push_201111151442.dat..
!!! Caught Server Exception
Taps Server Error: PGError: ERROR:  time zone displacement out of range: "2011-10-19 12:00:00.000000+5894049600"

["/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:175:in `async_exec'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:175:in `block (2 levels) in execute'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/logging.rb:28:in `log_yield'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:175:in `block in execute'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:158:in `check_disconnect_errors'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:175:in `execute'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:240:in `block (2 levels) in execute'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/connection_pool/threaded.rb:71:in `hold'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/connecting.rb:226:in `synchronize'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:240:in `block in execute'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:261:in `check_database_errors'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/adapters/postgres.rb:238:in `execute'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/query.rb:71:in `execute_dui'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:552:in `execute_dui'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:243:in `block (2 levels) in import'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:243:in `each'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:243:in `block in import'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/query.rb:223:in `_transaction'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/query.rb:209:in `block in transaction'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/connection_pool/threaded.rb:84:in `hold'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/connecting.rb:226:in `synchronize'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/query.rb:207:in `transaction'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/dataset/actions.rb:243:in `import'", "/app/lib/taps/data_stream.rb:315:in `import_rows'", "/app/lib/taps/data_stream.rb:158:in `fetch_remote_in_server'", "/app/lib/taps/server.rb:94:in `block (3 levels) in <class:Server>'", "/app/lib/taps/utils.rb:161:in `call'", "/app/lib/taps/utils.rb:161:in `server_error_handling'", "/app/lib/taps/server.rb:92:in `block (2 levels) in <class:Server>'", "/app/lib/taps/db_session.rb:15:in `block in conn'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/database/connecting.rb:76:in `connect'", "/app/.bundle/gems/ruby/1.9.1/gems/sequel-3.20.0/lib/sequel/core.rb:119:in `connect'", "/app/lib/taps/db_session.rb:14:in `conn'", "/app/lib/taps/server.rb:91:in `block in <class:Server>'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:865:in `call'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:865:in `block in route'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:521:in `instance_eval'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:521:in `route_eval'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:500:in `block (2 levels) in route!'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:497:in `catch'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:497:in `block in route!'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:476:in `each'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:476:in `route!'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:601:in `dispatch!'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:411:in `block in call!'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `instance_eval'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `block in invoke'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `catch'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `invoke'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:411:in `call!'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:399:in `call'", "/app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.1/lib/rack/auth/basic.rb:25:in `call'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:979:in `block in call'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:1005:in `synchronize'", "/app/.bundle/gems/ruby/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:979:in `call'", "/home/heroku_rack/lib/static_assets.rb:9:in `call'", "/home/heroku_rack/lib/last_access.rb:15:in `call'", "/app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.1/lib/rack/urlmap.rb:47:in `block in call'", "/app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.1/lib/rack/urlmap.rb:41:in `each'", "/app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.1/lib/rack/urlmap.rb:41:in `call'", "/home/heroku_rack/lib/date_header.rb:14:in `call'", "/app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.1/lib/rack/builder.rb:77:in `call'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/connection.rb:76:in `block in pre_process'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/connection.rb:74:in `catch'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/connection.rb:74:in `pre_process'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/connection.rb:57:in `process'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/connection.rb:42:in `receive_data'", "/app/.bundle/gems/ruby/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'", "/app/.bundle/gems/ruby/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/backends/base.rb:57:in `start'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/server.rb:156:in `start'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/controllers/controller.rb:80:in `start'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/runner.rb:177:in `run_command'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/lib/thin/runner.rb:143:in `run!'", "/app/.bundle/gems/ruby/1.9.1/gems/thin-1.2.7/bin/thin:6:in `<top (required)>'", "/usr/ruby1.9.2/bin/thin:19:in `load'", "/usr/ruby1.9.2/bin/thin:19:in `<main>'"]


pupeno commented Nov 17, 2011

For those having this issue, are you running Ruby 1.9.3-p0? Do you also get the problem with 1.9.2?

AA+++ would use @pupeno to debug again!!1!

pupeno commented Nov 17, 2011

@sillylogger as much as I'd love to take the credit, it belongs to Heroku's support.

With 1.9.2-p290 it's working


The problem is (I think), that marshalling changed between Ruby 1.9.2 and 1.9.3, so this is not really a taps error. Just use whatever version heroku runs to push and pull databases (Probably 1.9.2).

If you are using the cedar stack of heroku is also does not work with 1.9.2 !

+1 dang it.

This is a marshalling issue and not an issue with taps itself. Use the same Ruby version on both sides of the connection. This bug should be closed.

thefonso commented Mar 5, 2012

Keep this open til we have solution for cedar stack please...I'm having the same issue.

thefonso commented Mar 5, 2012

Confirmed. Database content transfer successful from localhost onto Heroku cedar via ruby 1.9.2 on localhost side. [for any noobs out there...look up "rvm"...you will need to install this and install ruby 1.9.2...the rvm website will tell you how....switch to 1.9.2 then attempt taps transfer as described here....http://devcenter.heroku.com/articles/taps]

help! when i try to switch to a different version of ruby i get a SEG fault and when i use 1.9.3 i get the timezone bs.

+1: 1.9.2p290 works just fine, but 1.9.3 barfs. Heroku has been great for getting n00bs into ruby/rails, but this issue makes attempts at indoctrination far less seamless, and markedly less effective.

If no fix is pending, could the error be caught and display a more easily comprehensible message that identifies the need for the same version on both sides?


pirj commented Mar 26, 2012


rahult commented Mar 29, 2012

It is working for me on ruby-1.9.2-p290 but not on ruby-1.9.3-p125

+! failing on 1.9.2 and 1.9.3

releu commented Apr 1, 2012

rvm install 1.9.2
rvm use 1.9.2@yourprojectname --create
heroku db:push --confirm yourprojectname

It works for me.

sborsje commented Apr 7, 2012

+1 failing on 1.9.3

sayanee commented Apr 8, 2012

+1 failing on ruby 1.9.3

avocade commented Apr 11, 2012

+1 failing on ruby 1.9.3-p125

+1 failing on ruby 1.9.3-p125

Same for me.

local machine ruby version:

ruby 1.9.3p125 (2012-02-16 revision 34643) [x86_64-darwin10.7.0]

Heroku server ruby version:

RUBY_VERSION        => ruby-1.9.3-p125

@kevinzen How did you get 1.9.3 up on Heroku? Also, even if this may be the Ruby version your app runs under, the Ruby instance that runs the taps server is probably still the standard 1.9.2. Does the problem go away when you use 1.9.2?

I got 1.9.3 on Heroku like this:


And yes, it worked when I switched to running 1.9.2 on my local machine. So it looks like an appropriate work around is to just run 1.9.2 wherever you are trying to upload the data from.

@kevinzen Okay, so taps seems to still use 1.9.2. If it actually failed with the same Ruby version on both sides, this would be a new bug.

I believe this is the same issue.

It looks as though taps is running on my local machine when it uploads the data, but that an instance of it is also running on heroku to receive the data and load the database. The error seems to be coming from the server-side version of taps that runs on heroku.

That is, the local version of taps grabs data and pushes it to heroku where another instance of taps receives it and loads the database. I believe the error is that the version of taps running on the local machine (under 1.9.3 locally) marshals timestamp fields incorrectly.

Then when it sends the timestamp fields to the taps server running on heroku, that server barfs because it can't unmarshall them in put them in the database.

I think it's likely that Heroku doesn't actually run taps on your instance either -- I believe that they probably run an instance of taps on some other server. I may be wrong on this.

Either way, the issue is in how the local version of taps is pulling timestamp fields out of the database and sending them.

Occurring with 1.9.2 for me.

Oh, and that is with the Heroku Cedar stack

sayanee commented Apr 23, 2012

I'm using ruby 1.9.3, but this fixed it for me.

rvm use ruby-1.9.2
heroku db:push
rvm use ruby-1.9.3


Isn't working for me with 1.9.2-p290 locally(using rvm) and on heroku, on the cedar stack.

ruby -v
ruby 1.9.2p290 (2011-07-09 revision 32553) [i686-linux]

heroku run 'ruby -v'
Running ruby -v attached to terminal... up, run.1
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]

Would it be worth trying a different 1.9.2 version?

avocade commented May 22, 2012


Would like to avoid installing ruby 1.9.2 on my Lion machine (requires pulling in the entire gcc compiler, according to ruby-build).

BM5k commented May 24, 2012

@kevinzen's explanation seems the most likely

my app: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
locally: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11.3.0]

and I'm seeing this error

!!! Caught Server Exception
Taps Server Error: PGError: ERROR:  time zone displacement out of range: "2012-05-14 12:00:00.000000+5894548800"
LINE 1: ...ices are free to clients.', false, '', false, '', '2012-05-1...

Installed 1.9.2-p320 & I was able to push.

+1 Occurring with 1.9.2-p320 (Heroku Cedar stack).

Is there any other alternative meanwhile? I'm completely stuck. Thanks!

As a temporary workaround I got rid of the not null constraints on my timestamps and deleted them by hand before doing the push. Not pretty, but I'm still early on in development.

Hoping for a proper fix soon!

I have solved this problem using Heroku PG Backups https://devcenter.heroku.com/articles/pgbackups

First you need to create a dump of the database in the localhost:

$ PGPASSWORD=mypassword pg_dump -Fc --no-acl --no-owner -h myhost -U myuser mydb > mydb.dump

Then, you just need to upload the dump to any HTTP server and run:

$ heroku pgbackups:restore DATABASE 'http://.../mydb.dump'

I was getting "Taps Load Error: no such file to load -- sqlite3" or "Taps Load Error: no such file to load -- pg" (not the time zone error) and I was using ruby 1.9.2-p320 (not 1.9.3)... Rolling back to ruby 1.9.2-p290 solved the problem.

Perhaps p320 has a similar issue as 1.9.3 or there's some weird dependency for Taps that it requires the exact same version (p290 presumably) on Heroku as locally. HTHs. Took me a while to guess that my Taps Load Error might be the ruby version 1.9.2 that I'd recently updated!

UPDATE: Btw, here are the rubies I'm using now--that are working--both on my local Darwin Mac and on Heroku:

$ heroku run 'ruby -v'
Running `ruby -v` attached to terminal... up, run.1
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]
$ ruby -v
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0]

dbrock commented Jul 18, 2012


macek commented Aug 8, 2012

This is not a Taps issue.

Use Heroku's pgbackups addon to manage import/export of your database and you won't have this issue.

heroku pgbackups

I found answer on this StackOverflow question

kinduff commented Nov 1, 2012


jfeust commented Nov 8, 2012

Switching to pgbackups is not a solution in my opinion. I love being able to easily push and pull individual tables "heroku db:push -t users". I've narrowed the issue down to the new heroku toolbelt. When using the older heroku gem i'm able to run db:push just fine. For now I've created a new gemset just to use the old heroku gem over the new toolbelt and it's working fine.



uri commented Jan 4, 2013


rcurtis commented Jan 6, 2013


doshea commented Jan 8, 2013


EDIT: I have solved the issue personally -- hopefully I can help some of you.

  1. Make sure your version of ruby matches the version running on Heroku. It seems like 1.9.2 is the stablest version for these migrations. This will solve most people's problems.
  2. Change your gemfile to have the following (assuming you're using SQLite):
group :development do
  gem 'taps', :require => false
  gem 'sqlite3'

If, like me, that STILL didn't solve your problem, it may be because your heroku db:push command is using the Heroku toolbar instead of the older, now-deprecated heroku gem. Unfortunately, we actually want the older gem, but the Heroku Toolbar is being called by heroku. To get around this, you will need to install the heroku gem on your version of ruby 1.9.2 and then access it by its specifiic filepath. For me, it was ~/.rvm/gems/ruby-1.9.2-p318/gems/heroku-2.33.5/bin/heroku db:push

My list of commands went like this:

rvm install ruby-1.9.2-p318
rvm use ruby-1.9.2-p318
bundle install
sudo gem install heroku --no-ri --no-rdoc


rake assets:clean
bundle exec rake assets:precompile


~/.rvm/gems/ruby-1.9.2-p318/gems/heroku-2.33.5/bin/heroku db:push

(use your own filepath, obviously)

+1 failing with ruby-1.9.3-p327
Thanks @doshea your suggestion worked perfect, i was able to upload my sqlite database

jfeust commented Jan 31, 2013

This issue has been figured out and the official word from Heroku is that db:push/pull is deprecated.

See: https://github.com/heroku/toolbelt/issues/34

The problem is with the newer toolbelt version of the heroku command line tool.

db:push works with

db:push does not work with

One workaround is to have an RVM gemset using the heroku gem 2.32.14 to do all your db:push/pulls. Heroku's solution is to just use bare postgresql pg_dump and pg_restore.

@doshea's fix worked for me as of this evening.

agile5 commented Sep 3, 2013

Great tips. New RVM gemset with these gems installed did the trick for me (I have 1.9.2 as one of my rubies anyway):

rvm use 1.9.2@taps2heroku
gem install heroku -v=2.32.14
gem install pg
gem install sqlite3
gem install taps
heroku db:push -a name-of-app

will commented Sep 3, 2013

heroku db:push and pull will soon be replaced with pg:push and pull, which won't use taps at all. If you want a preview check out heroku/heroku-pg-extras#42

@agile5 +1 Solid workaround.
How often do you push or pull your db anyways... a seperate gemset will do.

theareba commented Nov 2, 2013

I'm using rails 4 and ruby 1.9.3. I've installed ruby 1.9.2 but while bundle installing, I was prompted to change my ruby version on gem file to 1.9.2 which I did. Running again bundle install halts when installing active record saying active record 4.0.0 requires ruby v 1.9.3 or greater. How do I go about this. Please try to be clear on the gem file.

Error Gem::InstallError: activesupport requires Ruby version >= 1.9.3.
I'm using rails 4 and switched to ruby v 1.9.2, changing my gem file to
source 'https://rubygems.org'

gem 'rails', '4.0.0'
ruby "1.9.2"

doshea commented Nov 2, 2013

@theareba Why were you prompted to change to Ruby 1.9.2? Like your error message is saying, you simply can't run most of the Rails 4 components on Ruby 1.9.2. Nothing we can do about that, so you need to figure out why some of your gems want you to stay at 1.9.2.

Re-upgrade to 1.9.3 (change it in your Gemfile) and then let us know what the error/warning is that is telling you to downgrade to 1.9.2.

kinduff commented Nov 4, 2013

Are you guys having the same problem with pg:push & pg:pull?

doshea commented Nov 4, 2013

I was previously, but you're right that @theareba is off-topic. For those new to this thread, please disregard his questions and my response and apologies for detouring.

CJBrew commented Dec 11, 2013

Seriously, downgrading to 1.9.2 is the most horrible hack I can imagine. I'm still having the problem with Ruby 2.0.0 and downgrading breaks other dependencies. Why on earth hasn't this (apparently very basic functionality) been fixed?
Perhaps I'm getting my workflow wrong... Should I do all my content-adding on the production side and only use the development environment for modifying views etc (and perhaps testing those with sample data?). Otherwise, the lack of easy database transfer mechanisms is enormously frustrating

will commented Dec 11, 2013

Why on earth hasn't this (apparently very basic functionality) been fixed?

Taps is unmaintained and deprecated.

Yes, @will is correct, best to avoid using Taps. This SO post may be helpful to you (and any future persons finding this issue and wondering what to do).

CJBrew commented Dec 11, 2013

Yeah, I like the look of pg:push, but confusingly " pg:push is not a heroku command."
There's also pgtransfer http://www.higherorderheroku.com/articles/pgtransfer-is-the-new-taps/

will commented Dec 11, 2013

pg:push/pull was added in the heroku cli version 3.0.0. You can check your version with heroku version

CJBrew commented Dec 11, 2013

mystery partially solved. refinery-s3assets installed an old gem version of heroku (2.21.2) in my folder, which overrode the heroku toolset. Unfortunately the s3assets gem refuses to work with a later heroku...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment