Some of FilteringSpec tests fail when run locally

[flipp5b]

When I run integration tests locally using sbt core/IntegrationTest/test, a few tests inside the com.github.mjakubowski84.parquet4s.FilteringSpec fail:

[info] - should filter data by dateTime INT64 millis *** FAILED ***
[info]   1900-01-01T00:04:25 was not equal to 1900-01-01T00:34:08 (FilteringSpec.scala:118)
14:05:02.476 [pool-1-thread-1-ScalaTest-running-FilteringSpec] DEBUG c.g.m.parquet4s.ParquetReader$ - Creating ParquetIterable for path file:/tmp/example6726383439604235956/micros.parquet
14:05:02.564 [pool-1-thread-1-ScalaTest-running-FilteringSpec] DEBUG c.g.m.parquet4s.ParquetReader$ - Creating ParquetIterable for path file:/tmp/example6726383439604235956/micros.parquet
14:05:02.640 [pool-1-thread-1-ScalaTest-running-FilteringSpec] DEBUG c.g.m.parquet4s.ParquetReader$ - Creating ParquetIterable for path file:/tmp/example6726383439604235956/micros.parquet
[info] - should filter data by dateTime INT64 micros *** FAILED ***
[info]   1900-01-01T00:04:25 was not equal to 1900-01-01T00:34:08 (FilteringSpec.scala:118)
14:05:02.702 [pool-1-thread-1-ScalaTest-running-FilteringSpec] DEBUG c.g.m.parquet4s.ParquetReader$ - Creating ParquetIterable for path file:/tmp/example3995348077930743729/nanos.parquet
14:05:02.753 [pool-1-thread-1-ScalaTest-running-FilteringSpec] DEBUG c.g.m.parquet4s.ParquetReader$ - Creating ParquetIterable for path file:/tmp/example3995348077930743729/nanos.parquet
14:05:02.804 [pool-1-thread-1-ScalaTest-running-FilteringSpec] DEBUG c.g.m.parquet4s.ParquetReader$ - Creating ParquetIterable for path file:/tmp/example3995348077930743729/nanos.parquet
[info] - should filter data by dateTime INT64 nanos *** FAILED ***
[info]   1900-01-01T00:04:25 was not equal to 1900-01-01T00:34:08 (FilteringSpec.scala:118)

If I run sbt with TZ environment variable set (TZ=UTC sbt core/IntegrationTest/test), everything works fine.

[flipp5b]

It looks like the issue only manifests for some time zones.

• TZ=Europe/London sbt "core/IntegrationTest/testOnly -z com.github.mjakubowski84.parquet4s.FilteringSpec" - Success.
• TZ=Europe/Berlin sbt "core/IntegrationTest/testOnly -z com.github.mjakubowski84.parquet4s.FilteringSpec" - Success.
• TZ=Europe/Warsaw sbt "core/IntegrationTest/testOnly -z com.github.mjakubowski84.parquet4s.FilteringSpec" - Failure (1900-01-01T00:58:08 was not equal to 1900-01-01T00:34:08).
• TZ=Europe/Moscow sbt "core/IntegrationTest/testOnly -z com.github.mjakubowski84.parquet4s.FilteringSpec" - Failure (1900-01-01T00:04:25 was not equal to 1900-01-01T00:34:08).

[marcinaylien]

Ha!
Europe/Warsaw is treated by JVM (?) as the timezone used in Polish Commonwealth several hundred years ago :D

[mjakubowski84]

So, it is actually a bug in Java: https://stackoverflow.com/questions/47823081/java-sql-timestamp-wrong-time-parsing
In order to fix, one must avoid using Timestamp.valueOf or similar

[flipp5b]

Well, yeah :) Switching zeroDate to a more recent date (like LocalDate.of(2000, 1, 1)) works for all the time zones above.