-
Bug
-
Resolution: Done
-
Undefined
-
None
-
rhel-9.4
-
None
-
None
-
None
-
rhel-sst-cs-stacks
-
ssg_core_services
-
None
-
False
-
-
Yes
-
Red Hat Enterprise Linux
-
None
-
None
-
None
-
Enhancement
-
-
Done
-
None
What were you trying to do that didn't work?
Software expects to be able to read back a timezone name which is consistent with the configured name.
Please provide the package NVR for which bug is seen:
2.62-1.el9
How reproducible:
Any timezone which changed to "linked" will show this behaviour.
Steps to reproduce
use DateTime::TimeZone;
my $tz = DateTime::TimeZone->new( name => 'Europe/Copenhagen' );
my $name = $tz->name;
print "$name\n";
Expected results
Europe/Copenhagen
Actual results
Europe/Berlin
[RHEL-35685] Timezone name changes between set and get
tgc760 We are preparing documentation for this situation. I will close this ticket in the future without any code action. Thank you.
Tom Gravgaard Christensen
added a comment - Thanks for the reference.
The release shipped in RHEL 9.3, 2.47-3.el9, has no linked zones and the test program works as expected so the change in behaviour was surprising.
It broke a 3rd party software product that we use but I've since found that the vendor has added compatibility with linked zones in a later release so an update should solve our problem and allow us to upgrade to RHEL 9.4.
Tom Gravgaard Christensen
added a comment - Thanks for the reference.
The release shipped in RHEL 9.3, 2.47-3.el9, has no linked zones and the test program works as expected so the change in behaviour was surprising.
It broke a 3rd party software product that we use but I've since found that the vendor has added compatibility with linked zones in a later release so an update should solve our problem and allow us to upgrade to RHEL 9.4. 
Jitka Plesnikova
added a comment - It is expected behavior for linked zone as 'Europe/Copenhagen'.
From man page DateTime::TimeZone:
DateTime::TimeZone->new( name => $tz_name )
Given a valid time zone name, this method returns a new time zone blessed into the appropriate subclass. Subclasses are named for the given time zone, so that the time zone
"America/Chicago" is the DateTime::TimeZone::America::Chicago class.
If the name given is a "link" name in the Olson database, the object created may have a different name. For example, there is a link from the old "EST5EDT" name to
"America/New_York".
If you check DateTime::TimeZone::Catalog#Linked-Zones you find that 'Europe/Copenhagen' is alias for 'Europe/Berlin'.
Jitka Plesnikova
added a comment - It is expected behavior for linked zone as 'Europe/Copenhagen'.
From man page DateTime::TimeZone :
DateTime::TimeZone->new( name => $tz_name )
Given a valid time zone name, this method returns a new time zone blessed into the appropriate subclass. Subclasses are named for the given time zone, so that the time zone
"America/Chicago" is the DateTime::TimeZone::America::Chicago class.
If the name given is a "link" name in the Olson database, the object created may have a different name. For example, there is a link from the old "EST5EDT" name to
"America/New_York".
If you check DateTime::TimeZone::Catalog#Linked-Zones you find that 'Europe/Copenhagen' is alias for 'Europe/Berlin'. 
Knowledgebase article is available at https://access.redhat.com/articles/7071022
RHEL 9.4 Release Notes update has been published:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.4_release_notes/new-features#Jira-RHEL-35685
The same release note will be in RHEL 8.10 Release Notes when this document is published.