Wouldn't this depend on the column type you created in the database?

Not saying it shouldn't be a datetime, but changing this to *assume* 
it's a datetime field is a BC break.

I am surprised the bug is still open. Please kindly see enclosed file 
for a fix for both problems. The amended lines are marked with this 
ticket's number 14803

I found another little bug in Mapper.php. Function create (line 343 
ff.) should also use the Horde_Date object:

     public function create($fields)
     {
         // If configured to record creation and update times, set them
         // here. We set updated_at to the initial creation time so it's
         // always set.
         if ($this->_setTimestamps) {
             $time = time();
             $fields['created_at'] = new Horde_Date(time()); //$time;
             $fields['updated_at'] = new Horde_Date(time()); //$time;
         }

I was able to fix the described misbehaviour.
Please note the change around line 408 of enclosed Mapper.php:

[...]
         // If configured to record update time, set it here.
         if ($this->_setTimestamps) {
             //$fields['updated_at'] = time();
             $fields['updated_at'] = new Horde_Date(time());
         }
[...]

I am using an RdoMapper on a table created with $t->timestamps() on a 
Horde_Db_Migration_Base object. Columns created_at and updated_at are 
created right away in the backend.

According to Mapper.php (line 342 ff.), both fields should be set to 
the current timestamp on create(). According to lines 388 ff. 
updated_at should be set on update(). While created_at functions all 
right, updated_at remains set to 0000-00-00 00:00:00. No change on 
creation or update.