MSSQL returning wrong timezone info for Iran after DST stopped
mostafa8026 opened this issue · comments
Iran has recently stopped Daylight Saving Time (DST) for its timezone. However, I'm facing an issue while using mssql with docker 2019-latest and using the TZ=Asia/Tehran timezone.
When I check the date command inside the container, it returns the correct response as Wed Mar 22 16:05:15 +0330 2023. However, the select getdate() command in the SQL Server returns the wrong response, as it still considers Iran to have DST enabled.
I tried running the following query to check the time zone information in SQL:
SELECT name, current_utc_offset, is_currently_dst
FROM sys.time_zone_info
WHERE name like '%iran%'
It returned the following response:
Iran Standard Time +04:30 1
And also it's weird that the value of select CURRENT_TIMEZONE() is (UTC+03:30) Tehran
It seems that MSSQL is not properly updating its time zone information for Iran after DST has been stopped. Can anyone please suggest a solution or workaround for this issue? Thanks in advance!
Can you please file a support request for this? We will be happy to look into this for you and make necessary updates if required.
To submit a request through the Microsoft Support for Business portal, a licenseId is required. Since I am utilizing the free features and do not possess a licenseId, is there an alternative location where I can submit my inquiry?
Thanks @mostafa8026, a non-business support request can be opened via the general support process - https://support.microsoft.com/contactus. You can choose "Server Products" and SQL Server.
With that said, thank you for bringing this to our attention. We are looking into ways to support this scenario and will potentially deliver a fix when it’s ready. We would be unable to provide any timeline for any potential update, however, we would typically update the current version of SQL Server (SQL Server 2022 as of the date of this reply) before making changes to previous version of the product. SQL Server 2022 will also exhibit the reported behavior as of the date of this message. Please stay tuned.
As another avenue to submit your inquiry/potential bug, please use the Ideas (formerly known as User Voice) system - https://aka.ms/sqlfeedback and chose bug as the category.
Thank you for your response, @thesqlsith. I have submitted a bug report via the Ideas system as recommended (https://feedback.azure.com/d365community/idea/20f5a3c9-7fc9-ed11-a81b-00224850345d). This issue is causing significant disruption to our operations, and I would greatly appreciate any help or attention that can be given to resolve it as quickly as possible. Thank you for your assistance
Any update? I think it's an important bug.
Steps to reproduce the bug:
Step 1: Run a Docker container with SQL Server 2022 image:
docker run --rm -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=MyPassword123' -e 'TZ=Asia/Tehran' --name mssql-temp -d mcr.microsoft.com/mssql/server:2022-latest
This will download and start a new Docker container with SQL Server 2022 image. The -e options are used to set environment variables for the container, including the SA password and the time zone to be used.
Step 2: Connect to the running container:
docker exec -it mssql-temp bash
This will open a new terminal session inside the container.
Step 3: Run a SQL query using sqlcmd:
/opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P MyPassword123 -Q "SELECT name, current_utc_offset, is_currently_dst FROM sys.time_zone_info WHERE name like '%iran%'"
This command will execute the SQL query against the SQL Server instance running in the container and here is the buggy output:
name current_utc_offset is_currently_dst
---------------------------------------------------------
Iran Standard Time +04:30 1
Hello,
I encountered the same bug as described by @mostafa8026 in this GitHub issue regarding SQL Server and the timezone in Iran after DST has been stopped. It seems that MSSQL is not properly updating its time zone information for Iran after DST has been stopped.
As this is causing significant disruption to our operations, I kindly request the developers to find a solution or propose a hotfix as soon as possible. This is an urgent matter for me, and I would greatly appreciate any help or attention that can be given to resolve it as quickly as possible.
Thank you for your assistance.
Thank you @Jafar313.
We are looking into the issue, and do not have an updated timeline when a fix for the SYSDATETIMEOFFSET function will be addressed. That function is part of what the sys.time_zone_info view uses to determine the time zone offset. You can use the "old school" sp_helptext to see the definition of this catalog view if interested:
exec sp_helptext 'sys.time_zone_info'
This is why you are seeing an incorrect offset.
SELECT (SYSDATETIMEOFFSET() AT TIME ZONE name) AS AT_TIMEZONE, name as TimeZoneName
FROM sys.time_zone_info WHERE name like 'Iran%';
The other date/time related system function are correctly reading the offset from the operating system. For example, CURRENT_TIMEZONE, GETDATE, GETUTCDATE, and SYSDATETIME as can be seen if you run the following query:
SELECT
CURRENT_TIMEZONE() AS CURRENT_TIMEZONE,
GETDATE() AS GET_DATE,
GETUTCDATE() AS GET_UTC_DATE,
SYSDATETIME() AS SYS_DATE_TIME,
SYSDATETIMEOFFSET () AS SYS_DATE_TIMEOFFSET;
Please note, that the CURRENT_TIMEZONE function was added with the release of SQL Server 2022 - https://learn.microsoft.com/sql/t-sql/functions/current-timezone-transact-sql
As a workaround until we can address the issue with the SYSDATEIMEOFFSET function, we would recommend that you use one of the four functions that were mentioned above in your deployment process if the time zone offset information is needed in your pipeline.
The team is aware of the problem, and we will keep you updated via the Ideas Feedback item that was opened by @mostafa8026.
https://feedback.azure.com/d365community/idea/20f5a3c9-7fc9-ed11-a81b-00224850345d
Thanks @thesqlsith for your reponse.
But My main problem is with the getdate() itself. It should return the time for TZ=Asia/Tehran without DST. Take a look at the following step by step example:
step1: run the mssql docker:
docker run --rm -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=MyPassword123' -e 'TZ=Asia/Tehran' --name mssql-temp -d mcr.microsoft.com/mssql/server:2022-latest
step2: enter inside the docker:
docker exec -it mssql-temp bash
step3: the docker runtime date
$ date
date
Fri Apr 7 20:54:38 +0330 2023
step4: But the getdate() return 1 hour ahead
$ /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P MyPassword123 -Q "SELECT getdate()"
-----------------------
2023-04-07 21:54:40.727
and other related function:
$ /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P MyPassword123 -Q "SELECT CURRENT_TIMEZONE() AS CURRENT_TIMEZONE, GETDATE() AS GET_DATE, GETUTCDATE() AS GET_UTC_DATE, SYSDATETIME() AS SYS_DATE_TIME, SYSDATETIMEOFFSET () AS SYS_DATE_TIMEOFFSET;"
-----------------------------------------------------------------------------------
(UTC+03:30) Tehran
2023-04-07 21:56:48.607
2023-04-07 17:26:48.607
2023-04-07 21:56:48.6085090
2023-04-07 21:56:48.6085090
+04:30
Understood and thank you. Would you be able to just use either SYSUTCDATETIME() or GETUTCDATE() instead of GETDATE()? That should return the proper time with the appropriate offset since both are derived from the current local time and time zone settings of the OS where SQL Server is running (i.e. the host of the container in your case).
Thank you for your suggestion, @thesqlsith. Unfortunately, using SYSUTCDATETIME() or GETUTCDATE() instead of GETDATE() is not possible in our case as it would require significant changes to our legacy program and may introduce new bugs. We are hoping for a solution to the issue with getdate() itself.
Any news? I've seen that there is a new update (04/13/2023), but the issue remains unfortunately.
Hello @mostafa8026, unfortunately, the issue has not been resolved. We are continuing to work on the issue, but do not have an updated timeline when a fix will be available.
Please note that this is not specific to SQL Server on Linux, and we are addressing the problem for SQL Server in general. Once we address the general problem for the daylight savings change for Iran, SQL Server on Linux can be updated.
Why is SQL Server on Linux different in this case? Good question. The short answer if you are interested is that the SQL Server engine that runs on the Linux platform has a small dependency on a user mode version of Windows API's (so to speak). SQL Server is running within what we call a picoprocess, which is based on a Windows-based Library OS - https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-server-on-linux-how-introduction/. We refer to the entire architecture as SQLPAL which can be a little misleading, but the previous link breaks down each component more discretely.
If you really want to dig a bit deeper into SQLPAL, I encourage you to take a look at one of the All Systems Go presentations that was delivered a few years ago - https://media.ccc.de/v/ASG2019-131-how-microsoft-sql-server-went-multi-platform-sqlpal#t=7 as well as https://www.infoq.com/podcasts/slava-oks-linux-sql-server/
The Library OS is where the update for this issue will be made. We will update this thread and the Azure Ideas item that was filed as soon as we have a fix for the issue. Please stay tuned.
Hello @mostafa8026, just letting you know that the time zone change for Iran will soon be available for Windows systems - https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/iran-2023-time-zone-update-now-available/ba-p/3805707. This is relevant to the SQL Server on Linux issue that you have been facing because, as previously mentioned, we will be able to work on updating the SQLPAL layer (Library OS or LibOS for short) after general availability of the Windows update. With that said, we cannot provide a more precise timeline when a fix will be available, however, we are continuing to work on a resolution.
I can say that we will more than likely have an available fix for SQL Server 2022 on Linux before SQL Server 2019. This is because our release cadence for Cumulative Updates for SQL Server 2022 is shorter than SQL Server 2019 Cumulative Updates.
And for completeness, there is an overall DST related blog which can be found here - https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/bg-p/DSTBlog
Good day @mostafa8026, as an update to this thread, the time zone change for Iran should be available in the next CU for SQL Server 2022. We had released CU 5 for SQL Server 2022 (https://techcommunity.microsoft.com/t5/sql-server-blog/cumulative-update-5-for-sql-server-2022-rtm/ba-p/3849524) on June 15, 2023, so the next CU should contain the requested update.
I also had this issue and temporarily fixed it with this change:
GETDATE() => SWITCHOFFSET(GETUTCDATE(), '+03:30')
Update Cumulative Update 6 for SQL Server 2022 has been released (a few hours ago from the date/time of this post). The IRST issue has been resolved for SQL Server 2022. Please feel free to pull the latest docker image from our repo (i.e. mcr.microsoft.com/mssql/server:2022-latest).
Thanks, I've tested it and it was ok. Is there any update plan for sql 2019?
Thanks for the confirmation @mostafa8026. Since our release cadence is longer for SQL Server 2019 versus SQL Server 2022, the LibOS updates should be in the next CU (CU 22) for SQL Server 2019. You can view the historical release cadence for SQL Server 2019 here - https://learn.microsoft.com/troubleshoot/sql/releases/sqlserver-2019/build-versions#sql-server-2019-cumulative-update-cu-builds. This should provide you with a rough estimate as to when the next CU will be available.
We have had to occasionally delay the release when unexpected events occur, but the link above should provide you with a relatively good idea when to expect CU 22 for SQL Server 2019.