# Unexpected duplicate timestamps and missing hour around daylight-saving time **URL:** \ **Category:** Resolved Cases\ **Created:** [March 27, 2025, 9:57am UTC](https://forum.cloverdx.com/t/unexpected-duplicate-timestamps-and-missing-hour-around-daylight-saving-time/3235 "2025-03-27T09:57:38Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![CloverDX\_team](https://yyz1.discourse-cdn.com/flex007/user_avatar/forum.cloverdx.com/cloverdx_team/32/191_2.png) [@CloverDX\_team](https://forum.cloverdx.com/u/CloverDX_team)\ **Post date:** [March 27, 2025, 9:57am UTC](https://forum.cloverdx.com/t/unexpected-duplicate-timestamps-and-missing-hour-around-daylight-saving-time/3235/1 "2025-03-27T09:57:38Z")
We’re seeing unexpected behavior when querying datetime values from a SQL Server database through CloverDX—specifically around the daylight-saving time transition. Instead of receiving a record with a timestamp for 2:00 AM, the result includes **no 2:00 AM record** , and instead shows **two records for 3:00 AM**. This behavior only appears when running the query within CloverDX; running the same query directly in another SQL client returns the expected result, including the 2:00 AM timestamp. ---
**Author:** ![CloverDX\_team](https://yyz1.discourse-cdn.com/flex007/user_avatar/forum.cloverdx.com/cloverdx_team/32/191_2.png) [@CloverDX\_team](https://forum.cloverdx.com/u/CloverDX_team)\ **Post date:** [March 27, 2025, 1:03pm UTC](https://forum.cloverdx.com/t/unexpected-duplicate-timestamps-and-missing-hour-around-daylight-saving-time/3235/2 "2025-03-27T13:03:59Z")
What you’re observing is related to how **Java** , and by extension **CloverDX** , handles datetime values. In Java-based systems like CloverDX, date and time values are internally represented as numeric timestamps (milliseconds since `1970-01-01T00:00:00Z`). These numeric values are then **converted to human-readable date formats** using the **locale and regional settings** configured in the environment. So while your database (e.g., MSSQL) stores the specific datetime value, CloverDX may **display** that value differently based on: - The **locale and region** settings of the CloverDX Server or Designer - The **metadata configuration** in the graph (especially the date format and data type) - The **JVM locale settings** , which can affect how dates are interpreted and formatted This is especially noticeable around daylight-saving time transitions, where the conversion logic may shift or duplicate timestamps depending on the configured locale and how the time boundary is interpreted. ### How to address it: 1. **Clarify display vs. data** : It’s important to note that the **query results are not being altered** —only how those results are **rendered** in CloverDX. If you want to preserve the raw database format visually, you may need to work with string formats or carefully control the metadata used for display. 2. **Adjust metadata** : In CloverDX Designer, check the metadata used on the output port of your DatabaseReader. Make sure the **format** and **locale** are explicitly defined and appropriate for how you want the values to be displayed. 3. **Review locale settings** : CloverDX inherits locale settings from the OS or JVM. - For more information on how locale affects behavior in CloverDX Designer, refer to the documentation on [Locale and locale sensitivity](https://doc.cloverdx.com/latest/developer/metadata-records-and-fields.html#id_locale_and_locale_sensitivity). - To customize the locale in the CloverDX Server environment: - - Add the `-Duser.language=`and `-Duser.region=` **Java system properties** to your CloverDX Server startup configuration (i.e., add them to the `setenv.sh` or `setenv.bat` file, or, if you’re running **Tomcat as a Windows service** , add them to the **Java Options** section in the Tomcat service configuration UI).