Wrong timezone Information provided
Hello, some weeks ago the timezone data for Europe/Luxembourg changed on your side and a "Link Europe/Brussels Europe/Luxembourg" was added to https://data.iana.org/time-zones/tzdb/europe. This is wrong and results in the wrong timezone for Luxembourg and the wrong calculated time within Outlook and other applications. Can you please fix this. Thanks Best, Markus Torshizi Moghaddam Markus Torshizi Moghaddam Head of Customer Service markus.torshizi-moghaddam@cituro.com<mailto:markus.torshizi-moghaddam@cituro.com> Peter-Dörfler-Straße 30 | 86199 Augsburg Tel. +49 821 999 739 40 www.cituro.com/<https://www.cituro.com/> cituro GmbH, Amtsgericht Augsburg, HRB 36662 Geschäftsführung: Florian Heymel, Angie Wodarczyk [cid:image001.png@01D8D95B.2C271600]<https://www.cituro.com/> [cid:image002.png@01D8D95B.2C271600]<https://www.instagram.com/cituro_booking/> [cid:image003.png@01D8D95B.2C271600] <https://www.facebook.com/cituroDACH/> [Ein Bild, das Text, Transport, Axt, Rad enthält. Automatisch generierte Beschreibung] <https://twitter.com/cituroDACH> [Ein Bild, das Text, ClipArt enthält. Automatisch generierte Beschreibung] <https://www.xing.com/pages/cituro-gmbh> [cid:image006.png@01D8D95B.2C271600] <https://www.linkedin.com/company/cituro/> Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.
Markus Torshizi Moghaddam via tz said:
some weeks ago the timezone data for Europe/Luxembourg changed on your side and a "Link Europe/Brussels Europe/Luxembourg" was added to [1]https://data.iana.org/time-zones/tzdb/europe. This is wrong and results in the wrong timezone for Luxembourg and the wrong calculated time within Outlook and other applications. Can you please fix this.
Can you please be explicit what is wrong (e.g. "between <date> and <date> it should say UTC+2 but it's saying UTC+1"). Note that differences before 1970 are not considered significant in the main database. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 2022-10-06 09:35, Clive D.W. Feather via tz wrote:
Markus Torshizi Moghaddam via tz said:
some weeks ago the timezone data for Europe/Luxembourg changed on your side and a "Link Europe/Brussels Europe/Luxembourg" was added to [1]https://data.iana.org/time-zones/tzdb/europe. This is wrong and results in the wrong timezone for Luxembourg and the wrong calculated time within Outlook and other applications. Can you please fix this.
Could this describe your problem: https://techcommunity.microsoft.com/t5/outlook/outlook-meeting-after-dst-202... There is not necessarily a timely or definite link between time zone data updates and package or OS time zone updates, as the lead time for propagation varies greatly, especially to vendor mobile platforms depending on their age, quality of the product implementations using that data varies, and may depend also on the programming language of the implementation, some of which use the data in their own ways. This project provides a reference implementation, typically only used directly in open source Unix-like environments, and at best only as a basis by proprietary product vendors. Your best approach is to contact your time keeping or scheduling project or product vendor support forum or mailing list. The best this project can do may be to point you to a point of contact for the appropriate support organization, given sufficient information about your environment and issue.
Can you please be explicit what is wrong (e.g. "between <date> and <date> it should say UTC+2 but it's saying UTC+1"). Note that differences before 1970 are not considered significant in the main database.
Please also state the time zone selection named in the product with the issue, and the issue in terms of what you see or set, and what you expect, giving explicit dates and times? Please also give your Device, Platform, OS, Version, Edition, Service Level e.g. Mobile Samsung Galaxy S22 Android 12 2022-08, Mobile Apple iPhone 12 iOS 16.1, Desktop MS Windows 10 Home 21H2/2009 10.0.19044.1889, etc.; and your Product, Edition, Version e.g. MS Outlook Windows/Mac 365/Web/Desktop 9.99, and/or MS Exchange, and/or MS Findtime, and/or MS Calendar.Help, and/or MS Cortana, ..., etc.? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
On Oct 5, 2022, at 11:11 PM, Markus Torshizi Moghaddam via tz <tz@iana.org> wrote:
some weeks ago the timezone data for Europe/Luxembourg changed on your side and a “Link Europe/Brussels Europe/Luxembourg” was added to https://data.iana.org/time-zones/tzdb/europe. This is wrong and results in the wrong timezone for Luxembourg and the wrong calculated time within Outlook and other applications.
Is this all on Windows, or are there any UN*X systems - Linux, macOS, etc. - involved? I don't know whether anything in Windows, or any software from Microsoft that runs on Windows, uses the tzdb; there might be non-Microsoft software for Windows that does. For software that *does* use the tzdb, in tzdb-2022a, the information for Europe/Luxembourg was # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Europe/Luxembourg 0:24:36 - LMT 1904 Jun 1:00 Lux CE%sT 1918 Nov 25 0:00 Lux WE%sT 1929 Oct 6 2:00s 0:00 Belgium WE%sT 1940 May 14 3:00 1:00 C-Eur WE%sT 1944 Sep 18 3:00 1:00 Belgium CE%sT 1977 1:00 EU CE%sT and in tzdb-2022b, Europe/Luxembourg is a link to Europe/Brussels, and the Zone information for Europe/Brussels is # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Europe/Brussels 0:17:30 - LMT 1880 0:17:30 - BMT 1892 May 1 00:17:30 0:00 - WET 1914 Nov 8 1:00 - CET 1916 May 1 0:00 1:00 C-Eur CE%sT 1918 Nov 11 11:00u 0:00 Belgium WE%sT 1940 May 20 2:00s 1:00 C-Eur CE%sT 1944 Sep 3 1:00 Belgium CE%sT 1977 1:00 EU CE%sT The last two entries are identical; as of 1944-09-18, those are the entries in effect for both tzdb regions, so, unless the applications you are referring to are dealing with dates prior to 1944-09-18, there should be no difference whatsoever due to the tzdb change.
On 2022-10-06 3:49 PM, Guy Harris via tz wrote:
I don't know whether anything in Windows, or any software from Microsoft that runs on Windows, uses the tzdb; Windows derives its time zones from tzdb, mapped through Unicode Common Locale Data Repository (CLDR):
GitHub windowsZones.xml https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplementa... I believe this file is curated by Microsoft.
On 2022-10-06 13:01, Brooks Harris via tz wrote:
Windows derives its time zones from tzdb, mapped through Unicode Common Locale Data Repository (CLDR):
GitHub windowsZones.xml https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplementa...
I believe this file is curated by Microsoft.
Yes, as I understand it Microsoft Windows 8.1 and later has data derived from tzdb in its Windows Runtime / Universal Windows Platform classes. There's also Windows Subsystem for Linux, which is shipped by Microsoft and is a virtualized Ubuntu with its own copy of tzdb, though I doubt whether WSL is relevant here.
On 2022-10-06 4:07 PM, Paul Eggert wrote:
On 2022-10-06 13:01, Brooks Harris via tz wrote:
Windows derives its time zones from tzdb, mapped through Unicode Common Locale Data Repository (CLDR):
GitHub windowsZones.xml https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplementa...
I believe this file is curated by Microsoft.
Yes, as I understand it Microsoft Windows 8.1 and later has data derived from tzdb in its Windows Runtime / Universal Windows Platform classes. The time zone information resides in the Windows Registry, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
There's also Windows Subsystem for Linux, which is shipped by Microsoft and is a virtualized Ubuntu with its own copy of tzdb, though I doubt whether WSL is relevant here.
I do not have experience with WSL, but its said to run Linux *directly* within Windows, not as a virtual machine. What is the Windows Subsystem for Linux? https://learn.microsoft.com/en-us/windows/wsl/about
On Oct 6, 2022, at 1:25 PM, Brooks Harris via tz <tz@iana.org> wrote:
On 2022-10-06 4:07 PM, Paul Eggert wrote:
Yes, as I understand it Microsoft Windows 8.1 and later has data derived from tzdb in its Windows Runtime / Universal Windows Platform classes.
The time zone information resides in the Windows Registry, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
Is that what SystemTimeToFileTime() and FileTimeToSystemTime() use? If so, is it now derived from tzdb data?
There's also Windows Subsystem for Linux, which is shipped by Microsoft and is a virtualized Ubuntu with its own copy of tzdb, though I doubt whether WSL is relevant here.
I do not have experience with WSL, but its said to run Linux *directly* within Windows, not as a virtual machine.
What is the Windows Subsystem for Linux? https://learn.microsoft.com/en-us/windows/wsl/about
https://learn.microsoft.com/en-us/windows/wsl/compare-versions "WSL 2 uses the latest and greatest in virtualization technology to run a Linux kernel inside of a lightweight utility virtual machine (VM). However, WSL 2 is not a traditional VM experience." WSL 1 "[virtualizes] a Linux kernel interface on top of the Windows NT kernel": https://learn.microsoft.com/en-us/archive/blogs/wsl/windows-subsystem-for-li... whereas WSL 2 runs a Linux kernel inside the aforementioned lightweight VM. But none of that is relevant, as Paul suspected, to applications using the Windows API or the Windows Runtime / Universal Windows Platform APIs.
On 2022-10-06 14:25, Brooks Harris via tz wrote:
On 2022-10-06 4:07 PM, Paul Eggert wrote:
Yes, as I understand it Microsoft Windows 8.1 and later has data derived from tzdb in its Windows Runtime / Universal Windows Platform classes.
Uses MS port of tz code/data for UWP Store apps.
The time zone information resides in the Windows Registry, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
Used by native MS Windows libraries and apps: MS do their own thing here. It would not be too hard to convert from tz to MS reg data to provide correct times in earlier years. Windows dynamic time zones may have been added to support the EU 2006 and/or US 2007 changes, and new data is now added for other zones. The earliest dynamic zone I can find is for Cuba 2003. Base data is static current e.g. Cuba Standard Time Display (REG_SZ) = "(UTC-05:00) Havana" Std (REG_SZ) = "Cuba Standard Time" Dlt (REG_SZ) = "Cuba Summer Time" MUI_Display (REG_SZ) = "@tzres.dll,-2430" MUI_Dlt (REG_SZ) = "@tzres.dll,-2431" MUI_Std (REG_SZ) = "@tzres.dll,-2432" TZI (REG_BINARY) = 2c 01 00 00 00 00 00 00 but some zones also support 'Dynamic DST' e.g. FirstEntry (REG_DWORD) = 0x000007d3 (2003) LastEntry (REG_DWORD) = 0x000007dd (2013) 2003 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2004 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2005 (REG_BINARY) = f0 00 00 00 00 00 00 00 2006 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2007 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2008 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2009 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2010 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2011 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2012 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2013 (REG_BINARY) = 2c 01 00 00 00 00 00 00 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
It would not be too hard to convert from tz to MS reg data to provide correct times in earlier years.
Actually, it's quite a pain. The registry format presumes there are always exactly either zero or two DST transitions in every year. All kinds of workarounds are in place to deal with edge cases like standard time changing mid-year or DST ending permanently, etc. Not to mention time zones with 3 or 4 transitions, such as for Ramadan - which the OS has to handle special. Also, you'll find that the decisions about which time zones are grouped together start to get fuzzy as you go back in time. If you were to try to fill in the older data for all entries, you'd eventually encounter two differing IANA zones that are grouped under the same Windows zone, and you'd need a new Windows zone to split them apart. The 1970 rule we have in tzdata is 2010 in the Windows data. On Fri, Oct 7, 2022 at 11:03 AM Brian Inglis via tz <tz@iana.org> wrote:
On 2022-10-06 14:25, Brooks Harris via tz wrote:
On 2022-10-06 4:07 PM, Paul Eggert wrote:
Yes, as I understand it Microsoft Windows 8.1 and later has data derived from tzdb in its Windows Runtime / Universal Windows Platform classes.
Uses MS port of tz code/data for UWP Store apps.
The time zone information resides in the Windows Registry, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
Used by native MS Windows libraries and apps: MS do their own thing here. It would not be too hard to convert from tz to MS reg data to provide correct times in earlier years.
Windows dynamic time zones may have been added to support the EU 2006 and/or US 2007 changes, and new data is now added for other zones. The earliest dynamic zone I can find is for Cuba 2003.
Base data is static current e.g. Cuba Standard Time
Display (REG_SZ) = "(UTC-05:00) Havana" Std (REG_SZ) = "Cuba Standard Time" Dlt (REG_SZ) = "Cuba Summer Time" MUI_Display (REG_SZ) = "@tzres.dll,-2430" MUI_Dlt (REG_SZ) = "@tzres.dll,-2431" MUI_Std (REG_SZ) = "@tzres.dll,-2432" TZI (REG_BINARY) = 2c 01 00 00 00 00 00 00
but some zones also support 'Dynamic DST' e.g.
FirstEntry (REG_DWORD) = 0x000007d3 (2003) LastEntry (REG_DWORD) = 0x000007dd (2013) 2003 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2004 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2005 (REG_BINARY) = f0 00 00 00 00 00 00 00 2006 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2007 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2008 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2009 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2010 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2011 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2012 (REG_BINARY) = 2c 01 00 00 00 00 00 00 2013 (REG_BINARY) = 2c 01 00 00 00 00 00 00
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
WSL is an environment that runs a Linux distribution, such as Ubuntu. Within the distribution, tzdata and tzcode from this project are used just like they would be without WSL. So from the perspective of this project, WSL is just Linux. However, there is a bit of code in WSL itself to set the local time zone for the Linux environment, based on the Windows local time zone. Originally, this was done by faking a pseudo time zone entry in /usr/share/zoneinfo/Msft/localtime and hardlinking it to /etc/localtime. The pseudo-zone created lots of problems though, so I raised a bug about: https://github.com/microsoft/WSL/issues/3747 That was fixed in Windows 10 19H1. It now uses the ucal_getDefaultTimeZone function from ICU to resolve the correct *real* IANA time zone and links that instead. (ICU ultimately uses the CLDR windowsZones.xml file to make that determination.) -Matt On Thu, Oct 6, 2022 at 1:26 PM Brooks Harris via tz <tz@iana.org> wrote:
On 2022-10-06 4:07 PM, Paul Eggert wrote:
On 2022-10-06 13:01, Brooks Harris via tz wrote:
Windows derives its time zones from tzdb, mapped through Unicode Common Locale Data Repository (CLDR):
GitHub windowsZones.xml
https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplementa...
I believe this file is curated by Microsoft.
Yes, as I understand it Microsoft Windows 8.1 and later has data derived from tzdb in its Windows Runtime / Universal Windows Platform classes. The time zone information resides in the Windows Registry, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
There's also Windows Subsystem for Linux, which is shipped by Microsoft and is a virtualized Ubuntu with its own copy of tzdb, though I doubt whether WSL is relevant here.
I do not have experience with WSL, but its said to run Linux *directly* within Windows, not as a virtual machine.
What is the Windows Subsystem for Linux? https://learn.microsoft.com/en-us/windows/wsl/about
On 2022-10-06 14:01, Brooks Harris via tz wrote:
On 2022-10-06 3:49 PM, Guy Harris via tz wrote:
I don't know whether anything in Windows, or any software from Microsoft that runs on Windows, uses the tzdb; Windows derives its time zones from tzdb, mapped through Unicode Common Locale Data Repository (CLDR): GitHub windowsZones.xml https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplementa... I believe this file is curated by Microsoft.
This file is provided by Unicode related CLDR project to map from Windows time zones to tzdb time zones used to access their locale time data and allow related ICU project locale time to work under Windows. Updates have been provided by MS and IBM contributors, and ex-MS tz contributor Matt Johnson/-Pint. FYI Cygwin creates POSIX locale(7) objects from Windows locale data and POSIX locale settings, including mappings like date and time formats. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Exactly. Though truly the only owner is the Unicode CLDR project, and really anyone can submit PRs for that. It's also used heavily by browsers such as Chrome, such as if you call this JavaScript function to get your local time zone: Intl.DateTimeFormat().resolvedOptions().timeZone On Linux/Mac, the IANA time zone ID is already available, but on Windows it has to map through an ICU function, which uses the CLDR windowsZones.xml file. On Fri, Oct 7, 2022 at 10:07 AM Brian Inglis via tz <tz@iana.org> wrote:
On 2022-10-06 14:01, Brooks Harris via tz wrote:
On 2022-10-06 3:49 PM, Guy Harris via tz wrote:
I don't know whether anything in Windows, or any software from Microsoft that runs on Windows, uses the tzdb; Windows derives its time zones from tzdb, mapped through Unicode Common Locale Data Repository (CLDR): GitHub windowsZones.xml
https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplementa...
I believe this file is curated by Microsoft.
This file is provided by Unicode related CLDR project to map from Windows time zones to tzdb time zones used to access their locale time data and allow related ICU project locale time to work under Windows.
Updates have been provided by MS and IBM contributors, and ex-MS tz contributor Matt Johnson/-Pint.
FYI Cygwin creates POSIX locale(7) objects from Windows locale data and POSIX locale settings, including mappings like date and time formats.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
participants (7)
-
Brian Inglis -
Brooks Harris -
Clive D.W. Feather -
Guy Harris -
Markus Torshizi Moghaddam -
Matt Johnson-Pint -
Paul Eggert