Te damos el arreglo a esta contratiempo, al menos eso creemos. Si tienes interrogantes puedes escribirlo en el apartado de comentarios y con placer te ayudaremos
Solución:
Puede utilizar el equivalente del siguiente código Java:
static long dateTimeStringToEpoch(String s, String pattern)
return DateTimeFormatter.ofPattern(pattern).withZone(ZoneOffset.UTC)
.parse(s, p -> p.getLong(ChronoField.INSTANT_SECONDS));
Por supuesto, el procesamiento DateTimeFormatter.ofPattern(pattern).withZone(ZoneOffset.UTC) implica trabajo que podría evitarse al encontrarse con el mismo patrón string varias veces. Si esta cantidad de trabajo es relevante para su aplicación, depende de lo que se esté haciendo además de esta operación.
¿Puede probar este, según lo que ha dicho, está analizando la hora UTC, así que tengo esto como muestra?
Instant.parse("2019-01-24T12:48:14.530Z").getEpochSecond
Este es más de dos veces más corto (solo 3 llamadas de método):
def dateTimeStringToEpoch(s: String, pattern: String): Long =
LocalDateTime.parse(s, DateTimeFormatter.ofPattern(pattern))
.toEpochSecond(ZoneOffset.UTC)
Por cierto, construiría el DateTimeFormatter fuera de dateTimeStringToEpoch y pasarlo como un parámetro de método:
def dateTimeStringToEpoch(s: String, formatter: DateTimeFormatter): Long =
LocalDateTime.parse(s, formatter).toEpochSecond(ZoneOffset.UTC)
Después de ejecutar una prueba de rendimiento, hay poca diferencia en el rendimiento (apenas un factor de 2) al inicializar el DateTimeFormatter fuera del método.
scala> val pattern = "yyyy/MM/dd HH:mm:ss"
pattern: String = yyyy/MM/dd HH:mm:ss
scala> time(() => randomDates.map(dateTimeStringToEpoch(_, pattern)))
Took: 1216
scala> time(() => randomDates.map(dateTimeStringToEpochFixed))
Took: 732