pentaho timestamp issue
Pinging the list on the off chance someone has dealt with this and knows
of a workaroud. We have pentaho pointing to a PostgreSQL v10.3 database,
getting this error:
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - Timestamp : Unable to get
timestamp from resultset at index 55
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - Bad value for type
timestamp : 0001-02-04 17:00:04-06:59:56
2018/03/18 15:06:37 - INPUT STEP - Fact.0 -
2018/03/18 15:06:37 - INPUT STEP - Fact.0 -
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - at
org.pentaho.di.core.database.Database.getRow(Database.java:2302)
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - at
org.pentaho.di.core.database.Database.getRow(Database.java:2270)
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - at
org.pentaho.di.trans.steps.tableinput.TableInput.processRow(TableInput.java:153)
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - at
org.pentaho.di.trans.step.RunThread.run(RunThread.java:60)
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - at
java.lang.Thread.run(Unknown Source)
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - Caused by:
org.pentaho.di.core.exception.KettleDatabaseException:
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - Timestamp : Unable to get
timestamp from resultset at index 55
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - Bad value for type
timestamp : 0001-02-04 17:00:04-06:59:56
I've done some looking and this is clearly not a PostgreSQL issue, but
maybe there is an easy workaround? Anyone have any thoughts...
Thanks in advance
PropAAS DBA <dba@propaas.com> writes:
Pinging the list on the off chance someone has dealt with this and knows
of a workaroud. We have pentaho pointing to a PostgreSQL v10.3 database,
getting this error:
2018/03/18 15:06:37 - INPUT STEP - Fact.0 - Bad value for type
timestamp : 0001-02-04 17:00:04-06:59:56
Hmm. Presumably, this is coming from something that thinks that 1 AD
is outside the reasonable range of timestamps. Assuming you agree that
such a value shouldn't appear in your application, I'd look for timestamps
getting put into the database using to_timestamp() with a format string
that doesn't really match the data, causing the year field to be truncated
or misinterpreted.
regards, tom lane