Hello team, I wanted to bring up an issue related to the LDM model's handling of time zones in our database. We have a table with a TIMESTAMP_LTZ field, which stores times in

UTC

. For instance, consider a record with the timestamp

2024-03-31 22:30 UTC

. Our organization's settings convert this to

Europe/Stockholm

time zone, effectively changing it to

2024-04-01 00:30 CEST

. This transformation is working as expected. However, there seems to be a problem with our analysis filters. When filtering for

March 2024

, the mentioned record still appears, even though the timezone conversion places it in

April 2024

. Could we look into this? Thanks!

Hi Evangelos, if you have made changes to the LDM or the Data Source - Have you tried Reloading the Cached Data to ensure it matches the Data Source?

Hi @Michael Ullock, thanks for the reply😊 In the first screenshot you can see the analysis in Gooddata and in the second the record in our DB. Yes, cache was cleared when the problem was reported. The date fields are checked that they are the same.

Can I just clarify if you have correctly set the Time Zone Hierarchy for this workspace? As workspaces inherit the settings from their parent entity, i.e. parent workspace or organization - as mentioned here: https://www.gooddata.com/docs/cloud/customize-appearance/manage-timezones/ Could you let me know how you have this set please?

Hey @Michael Ullock , so here are the organization settings:

{
  "id": "55b00881-9300-4087-afe1-c610cc04594f",
  "type": "organizationSetting",
  "attributes": {
    "content": {
      "value": "Europe/Stockholm"
    },
    "type": "TIMEZONE"
  },
  "links": {
    "self": "<https://XXX.cloud.gooddata.com/api/v1/entities/organizationSettings/55b00881-9300-4087-afe1-c610cc04594f>"
  }
}

and no specific settings are being set for the workspace or his parent (which is the root).

Sorry for the delay in getting back to you - But I am currently discussing this case with our Product team. Once I have more details on this issue, I will let you know. Thanks for bearing with me in the meantime! 🙂

Thanks for the update! I appreciate you looking into this. Happy to assist if you need anything further from our side 🙂

Hi @Evangelos Malandrakis, the issue seems to be linked to time change which happened at 01:00 UTC on March 31, 2024 and manifests if start of date range interval and its end has different offset from UTC. We optimize date range conditions of generated SQL queries for performance and 1 month is added to the beginning of selected period to determine its end. Unfortunatelly, it is applied incorrectly. We will fix the problem. Thank you for reporting it!

Hi @Jakub Sterba, thank you for the detailed explanation! I appreciate the team's commitment to resolving this issue😊