North Africa Timezone changes around Ramadan

North Africa Timezone changes around Ramadan

Symptom:
North Africa clock changes around Ramadan. e.g., Morocco, that is included in DSTv34 which is not included in the current Oracle Database version ( 12.2 and 12.1 )
Oracle Database Cloud Schema Service – Version N/A and later: Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches
8:44
The changes included in DSTv34 patch (and not included in DSTv33) are:
• Brazil no longer observes DST.
• Palestine “springs forward” on 2019-03-30 instead of 2019-03-23.
• Fiji ends DST 2019-01-13
• Metlakatla “fell back” to rejoin Alaska Time on 2019-01-20 at 02:00.
• Qyzylorda, Kazakhstan moved from +06 to +05 on 2018-12-21.
• New zone Asia/Qostanay because Qostanay, Kazakhstan didn’t move.
• Metlakatla, Alaska observes PST this winter only.
• Morocco will continue to adjust clocks around Ramadan
8:45
H) Overview of what DST version is by default used / included in what Oracle RDBMS version and all DST patch numbers

8.1.7.4 and lower: has no timezone information
• 9.0.1 up to 9.2.0.8: includes and uses RDBMS DSTv1, includes and uses OJVM DSTv1
• 10.1 up to 10.2.0.2: includes and uses RDBMS DSTv2, includes and uses OJVM DSTv2
• 10.2.0.3: includes and uses RDBMS DSTv3, includes and uses OJVM DSTv3
• 10.2.0.4, 10.2.0.5 , 11.1.0.6, 11.1.0.7: includes and uses RDBMS DSTv4, includes and uses OJVM DSTv4
• 11.2.0.1:
• * includes all RDBMS DST updates from DSTv1 up to DSTv11, the default RDBMS DST version used is DSTv11.
• * includes and uses OJVM DSTv4
• 11.2.0.2:
• * includes all RDBMS DST updates from DSTv1 up to DSTv14, the default RDBMS DST version used is DSTv14.
• * includes and uses OJVM DSTv14
• 11.2.0.3:
• * includes all RDBMS DST updates from DSTv1 up to DSTv14, the default RDBMS DST version used is DSTv14.
• * includes and uses OJVM DSTv16
• 11.2.0.4:
• * includes all RDBMS DST updates from DSTv1 up to DSTv14, the default RDBMS DST version used is DSTv14.
• * includes and uses OJVM DSTv20
• 12.1.0.1:
• * includes all RDBMS DST updates from DSTv1 up to DSTv18, the default RDBMS DST version used is DSTv18.
• * includes and uses OJVM DSTv19
• 12.1.0.2:
• * includes all RDBMS DST updates from DSTv1 up to DSTv18, the default RDBMS DST version used is DSTv18.
• * includes and uses OJVM DSTv22
• 12.2.0.1:
• * includes all RDBMS DST updates from DSTv1 up to DSTv26, the default RDBMS DST version used is DSTv26.
• * includes and uses OJVM DSTv26
• 18.x:
• * includes all RDBMS DST updates from DSTv1 up to DSTv31, the default RDBMS DST version used is DSTv31.
• * includes and uses OJVM DSTv31
• 19.x:
• * includes all RDBMS DST updates from DSTv1 up to DSTv32, the default RDBMS DST version used is DSTv32.
• * includes and uses OJVM DSTv32

Solution:
Apply DSTv35 patch and upgraded the TIMEZONE from 18 to 34 first and then it is not fixed upgraded to 35. Showing the correct time zones from 19-APRIL to 31-MAY.
SQL> SELECT (FROM_TZ (TO_TIMESTAMP(‘202005241525′,’YYYYMMDDHH24MI’),’Africa/Casablanca’) AT TIME ZONE ‘UTC’ ) from dual;
(FROM_TZ(TO_TIMESTAMP(‘202005241525′,’YYYYMMDDHH24MI’),’AFRICA/CASABLANCA’)
—————————————————————————
24-MAY-20 03.25.00.000000000 PM UTC

SQL> SELECT (FROM_TZ (TO_TIMESTAMP(‘202005231525′,’YYYYMMDDHH24MI’),’Africa/Casablanca’) AT TIME ZONE ‘UTC’ ) from dual;
(FROM_TZ(TO_TIMESTAMP(‘202005231525′,’YYYYMMDDHH24MI’),’AFRICA/CASABLANCA’)
—————————————————————————
23-MAY-20 03.25.00.000000000 PM UTC

SQL> SELECT (FROM_TZ (TO_TIMESTAMP(‘202004191525′,’YYYYMMDDHH24MI’),’Africa/Casablanca’) AT TIME ZONE ‘UTC’ ) from dual;
(FROM_TZ(TO_TIMESTAMP(‘202004191525′,’YYYYMMDDHH24MI’),’AFRICA/CASABLANCA’)
—————————————————————————
19-APR-20 03.25.00.000000000 PM UTC

Leave a Reply

Your email address will not be published. Required fields are marked *