Con Laravel y SQL Server tuve muchos problemas con el formato en que se guardaba en el base de datos. Me resigne a una solución temporal, la cual consiste en setear el formato de fecha en cada modelo de la aplicación, definir accesores y mutadores (accessors and mutators). Lo cual no era lo más adecuado.
La solución fue definir un tamaño en el tipo de dato timestamp en las migraciones. Esto obliga a Laravel a definir el tipo de dato de las fechas en datetime2. Por último necesitamos remover en los modelos el formato y los mutadores (si no los utilizas).
Un ejemplo de la migración sería:
$table->increments('id_respaldo'); $table->text('observaciones')->nullable(); $table->date('fecha_respaldo'); $table->timestamp('fecha_creacion',4)->nullable(); $table->timestamp('fecha_actualizacion',4)->nullable(); $table->softDeletes('fecha_baja',4);
Como podemos ver fecha_creacion, fecha_actualizacion y fecha_baja son de tipo timestamp, lo cual Laravel convierte internamente a datetime2 de SQL Server con precisión de 4 fracciones de segundo según la documentación de datetime2 de SQL Server.
Sino le especificamos la precisión Laravel definirá el tipo de dato en datetime, lo cual causa los problemas ya mencionados en el post Error Datetime de SQL Server 2008 y Laravel 5.6: Data missing
Esto lo podemos ver en el siguiente código de Laravel incluido en la clase SqlServerGrammar:
protected function typeDateTime(Fluent $column) { return $column->precision ? "datetime2($column->precision)" : 'datetime'; }
Espero sea de ayuda. Saludos.
Comentarios1
Gracias!
Héroe! la mejor respuesta que he visto (incluyendo StackOverflow)