Time being shown in UTC even though database time is in IST

Hi,

I am using an SQL server which has the timezone set to IST. But when I am going through the data in metabase, the time column shows the time in UTC instead of IST.

My Report timezone in localization is set to "Asia/Kolkata" and the diagnostic info in troubleshooting also has the user.timezone set to "Asia/Kolkata".

Any help would be appreciated.

Hi @PD98
Post "Diagnostic Info" from Admin > Troubleshooting.
Timezones are difficult. Very difficult. Without knowing all your timezones and column data types, then it's very hard to say anything.
See https://www.metabase.com/docs/latest/troubleshooting-guide/timezones.html

Hi flamber,

This is the DIagnostic info :

{
  "browser-info": {
    "language": "en-US",
    "platform": "Win32",
    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36",
    "vendor": "Google Inc."
  },
  "system-info": {
    "file.encoding": "UTF-8",
    "java.runtime.name": "OpenJDK Runtime Environment",
    "java.runtime.version": "11.0.11+9-Ubuntu-0ubuntu2.20.04",
    "java.vendor": "Ubuntu",
    "java.vendor.url": "https://ubuntu.com/",
    "java.version": "11.0.11",
    "java.vm.name": "OpenJDK 64-Bit Server VM",
    "java.vm.version": "11.0.11+9-Ubuntu-0ubuntu2.20.04",
    "os.name": "Linux",
    "os.version": "5.11.0-25-generic",
    "user.language": "en",
    "user.timezone": "Asia/Kolkata"
  },
  "metabase-info": {
    "databases": [
      "mysql",
      "sqlserver"
    ],
    "hosting-env": "unknown",
    "application-database": "h2",
    "application-database-details": {
      "database": {
        "name": "H2",
        "version": "1.4.197 (2018-03-18)"
      },
      "jdbc-driver": {
        "name": "H2 JDBC Driver",
        "version": "1.4.197 (2018-03-18)"
      }
    },
    "run-mode": "prod",
    "version": {
      "date": "2021-07-14",
      "tag": "v1.40.1",
      "branch": "release-x.40.x",
      "hash": "ed8f9c8"
    },
    "settings": {
      "report-timezone": "Asia/Kolkata"
    }
  }
}

The server that the metabase instance is running on has the same timezone. The timezone in the sqlserver is also the same. The column which is showing this issue has field type as "No field type" and data type set as "type/Datetime"

@PD98
Metabase currently does not handle column types without timezone information:
https://docs.microsoft.com/en-us/sql/t-sql/functions/date-and-time-data-types-and-functions-transact-sql?view=sql-server-ver15
It is something we're trying to address in the upcoming 42 release (a couple of months away).

  1. If you are an Enterprise customer or trying a trial, then please use the support email.
    If you just want the free open source edition, then download the correct JAR file.
    https://github.com/metabase/metabase/releases
  2. You need to upgrade to at least x.40.5 - latest release is x.41.0
    https://github.com/metabase/metabase/releases
  3. You should migrate away from H2 if you are using Metabase in production:
    https://www.metabase.com/docs/latest/operations-guide/migrating-from-h2.html

Hi @flamber ,

In the link that you have shared, it is mentioned that the date and time values from the operating system are fetched.

Since the computer on which my sql server is running has the correct timezone set, can you please let me know as to why metabase is not able to correctly show the time value?

@PD98 Do this query in Metabase on the MSSQL db select current_timestamp; - that's not the same as a datetime column.

I cannot tell you how complicated timezones are, but it quickly becomes extremely complex. If you think there's an issue in Metabase, which you don't find in one of the many timezone issues, then please open a new issue with exact information on how to reproduce (otherwise it will never get fixed if it cannot be reproduced).
https://github.com/metabase/metabase/issues?q=is%3Aopen+is%3Aissue+label%3AMisc%2FTimezones

Anyway, like I already wrote, we are working on making it possible to define timezones much more granular in upcoming 0.42, so your problem would likely be fixed there.