Hello, I encountered a similar issue today, after France switched to daylight savings time yesterday, and I was only using DATEADD, not DATEDIFF.
I have tests that use a H2 db, and the data set is populated with timestamps relative to the current timestamp, using expressions such as DATEADD(DAY, -3, CURRENT_TIMESTAMP). Then there are some assertions about timestamps returned by queries, however these assertions failed today because of the 1h shift. Let's say current timestamp is 2023-03-27 18:00:00, and assertion expects a query to return a timestamp at same time of day 3 days ago, then the (computed) expected timestamp in Java would correctly be *2023-03-24 18:00:00*, while the actual timestamp returned by H2 would incorrectly be *2023-03-24 17:00:00* (thus not taking into account the switch from CET to CEST on 2023-03-26, as if it were just subtracting the product of the number of days by the number of millis in a 24h day). I'm using H2 version 2.0.206 and Java 8. My Java's DST database seems to be up-to-date since the expected timestamp (instantiated in Java test) successfully takes into account DST (using standard Calendar class to compute it). Le vendredi 1 avril 2016 à 08:32:21 UTC+2, Noel Grandin a écrit : Could you figure out which part of the computation is returning bad data? The DATEDIFF or the DATEADD? Should be possible by testing near the DST switchover datetime. Which version of H2 are you using? And are you running an up-to-date Java, so it's DST database is current? -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to h2-database+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/784bd4af-8be1-4b87-b5e9-962660f971cbn%40googlegroups.com.
