DateTime::TimeZone for Mexico City and Monterrey are not correct

[JamesRock11]

We are now experiencing an issue because this year after many years was the first time that there is no Summer time applied to Mexico City and others (I think Monterrey too) but our system did changed the time like if there was a Summer time here. First we thought that it was taken from the server but not, the server time now is fine (before yes it changed too incorrectly but now it is fixed) but still our OTRS system in Mexico City time zone is not right.

I saw that there was already some updates in your package 2 versions before that says "Changes in Greenland and Mexico" but I have updated our DateTime package to the latest and the problem is still there.

I am thinking is then I needed to report the issue to you so you can check if you need to do some adjustments to the TimeZone for Mexico City in your package, thank you. Right now is 10:25 in Mexico City and system is showing 11:25. System is setup as UTC time, thank you.

[spurthihemadri]

Iam also able to see the above issue for Mexico city.Any insights on this

[arodland]

The change in DateTime::TimeZone 2.56 and newer looks correct for America/Mexico_City. It says that the timezone became CST (UTC-6) on 2022-10-30 and does not change after that.

[spurthihemadri]

Eventhough i was on 2.60 version Still for mexico it was showing 1 hour ahead to Current Mexico

[autarch]

Here's the output I get from perl and date:

$> perl -MDateTime -E 'say DateTime->now(time_zone => q{America/Mexico_City})' ; TZ=America/Mexico_City date +'%Y-%m-%dT%H:%M:%S'
2023-06-11T08:14:07
2023-06-11T08:14:07

Can you provide an example of how these differ on your system?

[spurthihemadri]

/usr/share/zoneinfo is not been updated when DateTime-Timezone-2.60 module got installed .Does that means should i need to change something in tools directory

[autarch]

No, the DateTime-TimeZone module is only used for Perl code.

Other tools will use the system's IANA db. If they're out of sync that might explain what you're seeing. As to how it's updated, that varies across OS, though typically it's through the package manager on a Unix platform.

[spurthihemadri]

Since I am not able to see /usr/share/zoneinfo being updated when I updated to DateTime-Timezone that is the expected result right ,/usr/share/zoneinfo should be updated if it is not generating means where to look at actually

On Wed, Jun 14, 2023, 2:54 AM Dave Rolsky @.***> wrote:

No, the DateTime-TimeZone module is only used for Perl code.

Other tools will use the system's IANA db. If they're out of sync that might explain what you're seeing. As to how it's updated, that varies across OS, though typically it's through the package manager on a Unix platform.

— Reply to this email directly, view it on GitHub https://github.com/houseabsolute/DateTime-TimeZone/issues/55#issuecomment-1590045570, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQ3LJVCUOZSPIQYSR5BLDLXLDK7XANCNFSM6AAAAAAY4VGGTY . You are receiving this because you commented.Message ID: @.***>

[autarch]

Since I am not able to see /usr/share/zoneinfo being updated when I updated to DateTime-Timezone that is the expected result right ,/usr/share/zoneinfo should be updated if it is not generating means where to look at actually

I'm still not following. But again, there's no connection between updating DateTime-Timezone and updating your /usr/share/zoneinfo.

[spurthihemadri]

since my system had 2.37 module of Datetime and iam using 2023c tzdata with the 2.37 version .Still facing the offset for the mexico

[autarch]

I'm going to close this. I haven't seen any output from anyone's machine that shows DateTime-TimeZone is incorrect.

[JamesRock11]

Dear all, thanks for your help. In my case, I saw that the latest package was applied to the root user and not to the "otrs" user. I updated the packages to all users and now time is fine in Mexico timezone. Thank you!