Laravel-excel: problema de formato de fecha de importación de fragmentos

Cuando lo importa sin ->chunk() , ¿tiene el mismo problema?

sin trozo, funciona bien con reader-> formatdate ..., pero no puedo ir sin trozo porque el archivo es demasiado grande.

Probé con CSV, funciona bien porque csv elimina todos los cálculos y formatos, pero debe funcionar con xlsx.

Intente incluir también -> formatDates en este script.

Intenté con esto, pero no tuve éxito.

¿Puede compartir el código que funciona (sin fragmento) y el intento de fragmento con formatDates ()

Tengo el mismo problema, estoy importando un archivo xls con el método chunk, pero convierte la fecha en un formato flotante y no puedo acceder a la variable $ reader para establecer cuáles son las columnas de fechas.

¿Ha encontrado alguna solución?

Gracias

finalmente resolví esto convirtiéndolo primero en un archivo csv y luego cargando nuevamente este csv, porque csv elimina todo el formato, etc.

Solo tenemos este problema en un proyecto nuestro. Al fragmentar un archivo de Excel (que actualmente contiene algo así como 10 filas), perdemos el formato de las celdas definidas como fechas; simplemente aparecen como números como 27777.

Logramos resolver eso en este caso al no usar fragmentación y para este proyecto eso podría funcionar. Creo que el problema es que en la línea 496 de LaravelExcelReader.php se activa la función setReadDataOnly. Según https://github.com/PHPOffice/PHPExcel/issues/15, tenerlo activado significa que las celdas de fecha no se analizan correctamente.

¡El mismo problema aqui!

¿Ha encontrado alguna solución?

Experimentando el mismo problema con la siguiente configuración (simplificada) ...

Mi archivo de Excel:

| nombre | fecha_nacimiento |
| --- | --- |
| John Smith | 09/09/1987 |

Importar código en mi controlador usando chunk:

$file = \Input::file('student_file');

\Excel::filter('chunk')
    ->selectSheets('students')
    ->load($file)
    ->formatDates(true)
    ->chunk(250, function($results) {

        dd($results);

    });

Resultado de dd() :

RowCollection {#1019 ▼
  #title: null
  #items: array:1 [▼
    0 => CellCollection {#789 ▼
      #title: null
      #items: array:9 [▼
        "name" => "John Smith"
        "birth_date" => 32029.0
      ]
    }
  ]
}

Si no utilizo el filtro de fragmentos, como tal:

\Excel::selectSheets('students')
    ->load($file, function($reader) {

        dd($reader->get());

    });

Obtengo lo siguiente del dd() :

RowCollection {#527 ▼
  #title: "students"
  #items: array:1 [▼
    0 => CellCollection {#628 ▼
      #title: null
      #items: array:9 [▼
        "name" => "John Smith"
        "birth_date" => Carbon {#627 ▼
          +"date": "1987-09-09 00:00:00.000000"
          +"timezone_type": 3
          +"timezone": "Europe/London"
        }
      ]
    }
  ]
}

¿Alguna sugerencia?

Informar de un problema por mi parte también.

get () funciona y devuelve un objeto Carbon, chunk () devuelve un flotante.

EDITAR: en el último "maatwebsite / excel": "~ 2.1.0",

Tener el mismo problema con el filtro de importación de fragmentos y las fechas que se leen como flotantes.

El mismo problema aquí con chunk. Nuestra solución fue agregar el campo de fecha de $row a una fecha base (1900-01-01):

$date_aux = Carbon::create(1900, 01, 01, 0);
$date_correct = $date_aux->addDays($row->date_wrong - 2);

Tienes que restar 2 de la fecha incorrecta para obtener la correcta.

Espero que esto ayude.

El mismo problema aqui

El mismo problema aqui

El mismo problema aqui

el mismo problema aqui

Este problema podría resolverse mediante
$ FECHA_UNIX = ($ fila-> DOB - 25569) * 86400;
$ columna_fecha = fecha_gm ("dmY H: i: s", $ FECHA_UNIX);

¿Un error tan antiguo y sin solución propia? ... ¡El mismo problema!
Gracias, bsiu

+1

Otra solución es establecer las columnas de fechas en la configuración de manera programática antes de realizar la llamada chunk :

config(['excel.import.dates.columns' => [
            'deleted_at,
            'updated_at'
        ]]);

Excel::filter('chunk')->load($file)...

+1 tiene el mismo problema. Cuando se usa chunk, no parece convertir las fechas correctamente. Si lo hago:

$import = Excel::filter('chunk')->load($file)->setDateColumns(['my_date'])->chunk(1, function($results) {
    dd($results);
}, false);
// my_date is a numeric value

Con:

$import = Excel::load($file)->setDateColumns(['my_date'])->dd();
// my_date is carbon.

@jamestowers esa es una buena solución: recuerde que si usa fragmentos en cola, recuerde llamar a config en un proveedor de servicios o algo, de lo contrario, no funcionará. Espero que este error se solucione pronto @patrickbrouwers

Mismo problema. Nombrar columnas de fecha no es la solución que estábamos buscando, pero lo hará ahora. ¿Por qué no leer valores Y formatos (pero no estilos y otras cosas), PHPExcel?

Me encontré con este problema hoy, 2 años desde que se informó, todavía no se ha resuelto. proyecto abandonado?

Mismo problema: +1:

De hecho, el problema ocurre porque, como dijo @cooperaj , setReadDataOnly se establece en true en ChunkedReadJob. Comentar esta línea resuelve este problema.

@patrickbrouwers Me complacería proporcionar un PR para esto, pero creo que tuvo una razón para deshabilitar la obtención del formato de las celdas en ChunkedReadJob.

Dado que tanta gente tiene este problema, sería genial si pudiéramos abordarlo de alguna manera.

Resolvió el problema con esta línea.

setDateColumns () viene como un salvador

$ lista de vacaciones = Excel :: load ('almacenamiento / app / public / lista de vacaciones.xlsx', función ($ lector) {}) -> setDateColumns (['feriado_fecha_inicio', 'feriado_fecha_final']) -> get ();

Me he estado tirando de los pelos por este. ¿Por qué no está arreglado? He perdido dos plazos debido a un problema de Mickey Mouse en una rutina de importación de Excel que tiene más de 2 años.

la solución es que cuando lea la fecha del tipo de columna, debe formatearla en una cadena, así que intente esto, por favor
\PHPExcel_Style_NumberFormat::toFormattedString($row['date_example'], 'YYYY-MM-DD']

Estamos cerrando todas las entradas antiguas, porque la versión 2. * está llegando al final de su vida útil. Ahora dedicamos toda nuestra atención a la versión 3.0. Todavía es posible usar 2. *, pero ya no habrá soporte activo.