-
Notifications
You must be signed in to change notification settings - Fork 343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spring-data-jdbc and postgres: Trailing junk on timestamp #935
Comments
i have no idea what the problem is, if it is postgresql or spring-data related, or if there is something wrong in our application. And if so, why did it work until I upgraded spring boot? Any hints would be much appreciated. |
I haven't found the exact reason yet of what is going wrong. I'm always very sceptical when I see time and date like datatypes with timezone information used in persistent storage, since it seems to mingle two very different concepts: a point in time and a rough approximation of a location/cultural context. Most of the time |
Also ran into this issue today, but with SpringBoot 2.4.3. We also are running postgresql. The issue occurs when we run updates on a table of the form (other fields omitted): @Table("table_name")
data class MyTable(
@Id @Column("id") val id: UUID,
@Column("created_at") val createdAt: OffsetDateTime = OffsetDateTime.now(),
@Column("updated_at") val updatedAt: OffsetDateTime = OffsetDateTime.now()
) The code works for a different table that doesn't have an updated_at field, i.e. it looks like the following (other fields omitted): @Table("table_2_name")
data class MyOtherTable(
@Id @Column("id") val id: UUID,
@Column("updated_at") val createdAt: OffsetDateTime = OffsetDateTime.now()
) |
@schauder The application (that I kind of inherited) uses UTC for all dates (and for |
Also ran into the problem today. But I would have blamed the PostgreSQL driver for not corectly parsing the OffeseDateTime string representation. It does not expect the seperating 'T'. However PostgreSQL documentation suggests, it should work. |
The problem seems to be that we are now setting the |
Dialects may now register a list of converters to take into consideration when reading or writing properties. See `JdbcSqlServerDialect` for an example. By default `OffsetDateTime` does not get converted anymore. If a database needs a conversion it can register it by implementing `Dialect.getConverters()` as described above. Closes #935
I just created a PR that hopefully fixes the issue. If anybody can give that a try, that would be helpful. Note, that in it's current form it breaks code that inherits from |
Dialects now can define a set of known simple types the driver can handle without further interaction. This is done to avoid warnings during converter registration for types known in one environment but not the other. Also move types around a bit, change visibility and make sure jdbc specific dialects inherit converters from their parents. Original pull request #981 See #935
I'm still getting "Trailing Junk on timestamp: 'T07:02:27.894774Z'". I've even aligned OffsetDateTime to UTC using following snippet var odtNow = OffsetDateTime.now().withOffsetSameInstant(ZoneOffset.UTC); Are we supposed to use |
The problem is only in so far the JDBC driver that the JDBC driver of most databases just drops the timezone. Do you use one of the 2.3 milestone releases of Spring Data JDBC? |
- Oppdatert KafkaErrorHandler til å arve DefaultErrorHandler - Oppdatert Kafka config. - Endre til bruk av Instant i stedet for OffsetDateTime på grunn av mulig bug i Spring: spring-projects/spring-data-relational#935 Skulle vært fikset i spring-data-jdbc-2.3.0, men ser ut som det ble igjeninnført med spring-boot-2.6.1.
Original question here: https://stackoverflow.com/q/66484578
Small gradle project with a junit test to reproduce the error: https://github.com/schachtelhalm/minimal-demo
With spring boot 2.3.8 this junit test doesn't fail, with 2.3.9 it fails with
java.lang.NumberFormatException: Trailing junk on timestamp: 'T21:26:13.318881+01:00'
Tested with openjdk 11.0.10.
Complete stacktrace on minimal-demo page.
The query method is in a Repository that extends
CrudRepository
:The entity has a field
private Timestamp updatedAt;
When I tried to debug the original application I set a breakpoint in
org.postgresql.jdbc.TimestampUtils.parseBackendTimestamp()
. With spring boot 2.3.8 I think I only hit the method for timestamps from the database rows, but not for the parameter of the query. With 2.3.9 the methodparseBackendTimestamp()
was also called for the parameter I'd used with curl requests for the RestController.The text was updated successfully, but these errors were encountered: