- tz - lists.iana.org

Issue with timezone
by Ty Hanks July 18, 2023

July 18, 2023

Having an issue with timezone ‘America/Bogota’ should be the same as ‘America/NewYork’ but if you pull time based on it from pytz which uses your database. You get the wrong timezone a 3 or 4 hour ahead timezone. Feel free to ask for more testing info if needed .. Thanks

4 3

TZDB 2023c build issues with ARM busybox
by Rajesh Subramanian July 11, 2023

July 11, 2023

Hi Team, I am trying to compile the TZDB in ARM busysbox version: 2023c After compiling the executable during the installation stage, got an error while trying to create the timezone files using tzdata.zi. Could you please help on what is wrong here? make BACKWARD='backward' DESTDIR='/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/niagara-staging/tmp/tz' LEAPSECONDS='' PACKRATDATA='' PACKRATLIST='' TZDEFAULT='/etc/localtime' TZDIR='/usr/share/zoneinfo' ZIC='./zic ' LEAPSECONDS= install_data make[1]: Entering directory '/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/tz/tz-2023c' ./zic -v -d '/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/niagara-staging/tmp/tz/usr/share/zoneinfo' tzdata.zi *./zic: 1: Syntax error: word unexpected (expecting ")")* make[1]: *** [Makefile:697: install_data] Error 2 File format for the executable: file zic is linked with the expected host architecture. *zic*: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=48cd5d62692908a4f58468f5077d4187fe06c825, not stripped Regards, Rajesh

4 3

Error in Scandinavian tz data
by Anders Rosendahl June 28, 2023

June 28, 2023

Hello! I'm developing an application using the JavaScript Intl API (which is relying on the IANA tz db) for converting between local time and UTC. I started receiving error reports from users about wrong calculations (particularly from Denmark in the 1940's), and I discovered that in some cases daylight saving time was applied in a way not in accordance to historical facts. I investigated the IANA tz database files and I discovered that a change has happened in version 2022b (in the file "europe"). Compared to the earlier version (2022a), 4 zones seem to have their rules removed and instead linked to Europe/Berlin: Link Europe/Berlin Arctic/Longyearbyen Link Europe/Berlin Europe/Copenhagen Link Europe/Berlin Europe/Oslo Link Europe/Berlin Europe/Stockholm This, evidently, is not correct, and will result in erroneous results for these zones. Best wishes, Anders Rosendahl

7 11

Re: [tz] [libc-coord] thread-safe localtime() for an arbitrary timezone
by Paul Eggert June 21, 2023

June 21, 2023

On 2023-06-15 10:03, enh wrote: > any thoughts on either renaming `struct state` (i went with `struct > __timezone_t` to match the typedef to timezone_t for the pointer) or having > a knob for that (i added a `#define state __timezone_t` in the `#if > NETBSD_INSPIRED` in private.h)? why do i care? because tzcode pulls in the > system <time.h>, which is actually fine for the tzcode code, but breaks the > OpenBSD wcsftime(). We could rename 'struct state', but I'm a bit lost as to what the problem is, as I don't see mention of 'state' or 'timezone_t' in openbsd/lib/libc/time/wcsftime.c. Although there is a 'struct state' in openbsd/lib/libc/time/localtime.c I assume you're replacing that with tzcode's localtime.c somehow. User apps (which tzcode is, by default) shouldn't define symbols like __timezone_t because these symbols are reserved to the system. We could easily rename 'struct state' to 'struct timezone_struct' so that you could compile with -Dtimezone_struct=__timezone_t, though I'm still curious about why 'struct state' causes problems. I'll cc this to the tz mailing list to see whether other people there have insight into this issue. For those new to the discussion, the original thread is archived here: https://www.openwall.com/lists/libc-coord/2023/06/14/1

4 14

Iran Time Zone is Incorrect in Your Database
by Mohammad Ahmadian June 2, 2023

June 2, 2023

Hello, Thanks for your service. This year, the Iran government decided to cancel the daylight time zone. So they did not change the time zone to 04:30. It is now 03:30. I updated my tablet via this application to the latest version of your database successfully: https://github.com/meefik/tzupdater But the time zone is wrongly 04:30 again. Please change your database. Let me know what you think and do. Thank you

2 1

Tzdb build issue
by Naveen kumar June 1, 2023

June 1, 2023

Hi Team, I am facing this issue while compiling the tzdata latest version tzdb-2023c.I attached the log for your reference. Thanks, Naveen.

4 9

[PROPOSED] Update tzselect comment
by Paul Eggert June 1, 2023

June 1, 2023

* tzselect.ksh: Update comment, as Oracle has extended the end-of-life date for Solaris 10. --- tzselect.ksh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzselect.ksh b/tzselect.ksh index 9a91acfc..98774c03 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -21,7 +21,7 @@ REPORT_BUGS_TO=tz(a)iana.org # MirBSD Korn Shell <http://www.mirbsd.org/mksh.htm> # # For portability to Solaris 10 /bin/sh (supported by Oracle through -# January 2024) this script avoids some POSIX features and common +# January 2025) this script avoids some POSIX features and common # extensions, such as $(...) (which works sometimes but not others), # $((...)), ! CMD, ${#ID}, ${ID##PAT}, ${ID%%PAT}, and $10. -- 2.39.2

2 1

[PATCH] Ask for POSIX-conforming ‘make’
by Paul Eggert May 31, 2023

May 31, 2023

* Makefile (.POSIX): New target. I discovered the need for this when I ran ‘make -n’ and GNU Make executed recipe lines containing $(MAKE) even though they had side effects. When run in POSIX mode, GNU Make won’t execute recipe lines unless they begin with ‘+’. POSIX says the behavior of ‘make’ is undefined unless the Makefile’s first non-comment line has a ‘.POSIX’ target. --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index 8017a14e..da3ee259 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,6 @@ # Make and install tzdb code and data. +# Request POSIX conformance; this must be the first non-comment line. +.POSIX: # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. -- 2.39.2

1 0

Europe/Tiraspol problem
by Yoshito Umaoka May 19, 2023

May 19, 2023

Dear all, I was looking at some Unicode ICU test failure on Ubuntu related to time zone. ICU utilizes TZ database including backward file. In backward file, Europe/Tiraspol is defined as a link of Europe/Chisinau. So the actual rule is coming from Europe/Chisinau as below (2023c) # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Europe/Chisinau 1:55:20 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT 1:44:24 - BMT 1931 Jul 24 # Bucharest MT 2:00 Romania EE%sT 1940 Aug 15 2:00 1:00 EEST 1941 Jul 17 1:00 C-Eur CE%sT 1944 Aug 24 3:00 Russia MSK/MSD 1990 May 6 2:00 2:00 Russia EE%sT 1992 2:00 E-Eur EE%sT 1997 # See Romania commentary for the guessed 1997 transition to EU rules. 2:00 Moldova EE%sT I found behavior of Europe/Tiraspol is different on Ubuntu. When I set Europe/Tiraspol as the system time zone, the default offset set to timezone variable becomes -10800 (3 hour ahead of UTC). However, Europe/Chisinau above shows it should be -7200 (2 hour ahead of UTC) at this moment. (POSIX timezone variable should store “standard offset”, not counting daylight adjustment). On Ubuntu, when I set Europe/Tiraspol as system time zone, -10800 is set to timezone variable. However, when I set Europe/Chisinau, it changes to -7200. Then I realized Ubuntu is using backzone file, which contains different rule. In backzone file, Europe/Tiraspol is defined as below (2023c) # Moldova / Transnistria Zone Europe/Tiraspol 1:58:32 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT 1:44:24 - BMT 1931 Jul 24 # Bucharest MT 2:00 Romania EE%sT 1940 Aug 15 2:00 1:00 EEST 1941 Jul 17 1:00 C-Eur CE%sT 1944 Aug 24 3:00 Russia MSK/MSD 1991 Mar 31 2:00 2:00 Russia EE%sT 1992 Jan 19 2:00 3:00 Russia MSK/MSD I understand backzone was created for preserving zone definition of some locations which only differs pre-1970 date, and these data might not be reliable. In reality, I think most of TZ database consumer still rely on either backward or backzone for backward compatibility. I think it’s problematic if these two files produce different results today. I guess the zone definition in backzone file might be outdated, and Tiraspol is actually UTC+2/+3. -Yoshito

2 1

Buggy %z behaviour in strftime
by Almaz Mingaleev May 16, 2023

May 16, 2023

Attached code prints "+0000 America/Los_Angeles" both with glibc and with linked ToT strftime implementation. On MacOs it prints "-0800 America/Los_Angeles". Is it a known issue?

10 19

Changes to DST in IR/Tehran timezone
by Jafari Abolfazl May 16, 2023

May 16, 2023

Hello. First of all thanks for maintaining database and second I hav to excuse for my English before hand, cause I am not a native and maybe do some mistakes. Due to goverments choices, starting from 21st March 2023, Iran dismissed DST and now time should stay at +3:30, but due to lack of contacting with official channels, it seems lots of systems still use 2023c tz database and time is +4:30. This problem cause so many problem specially in smartphone that due to lack of automatic time, many application won't work correctly.

3 2

Web sites using recent versions of the tz database
by Sylvia May 10, 2023

May 10, 2023

Dear team, My name is Silvia, I am the webmaster responsible for carta-natal.es. This is an astrology website wich uses the latest version of the TZ database for calculating astral charts with the correct UT hour and date. It includes a section where you can see the timezone details and time changes of each town throughout history: https://carta-natal.es/zona_horaria.php https://carta-natal.es/cambios_horarios.php Of course there could be some (mine/human) error in associating a time zone identifier to each locality. Do you think it would be possible and/or useful to add carta-natal.es to the web sites list at https://carta-natal.es/cambios_horarios.php? Thank you very much. kind regards, Silvia

1 1

More prominent/consistent record of rule change notification date?
by Jan Harris May 8, 2023

May 8, 2023

Greetings I deal with getting the TZ updates rolled out for IBM AIX. As we all know, sometimes IANA is notified in the eleventh hour, and it is not feasible for AIX to deliver fixes in a matter of weeks (or less) Take Egypt, for example. For good reason, IANA did initiate a new build on March 1, as discussed in this thread<https://mm.icann.org/pipermail/tz/2023-March/032683.html>. (Even if they did, it would have been a tight schedule for AIX to have ready mid April.) I certainly appreciate the emphasis on notifications, placed in the IANA article. How Time Zones Are Coordinated<https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03…> * https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03… I have incorporated this message in to our AIX TZ documentation. We usually see some attribution to the notification in the NEWS Starting in 2023, Egypt will observe DST from April's last Friday through October's last Thursday. (Thanks to Ahmad ElDardiry.) Assume the transition times are 00:00 and 24:00, respectively. I think it would be helpful if there was a clear record of WHEN IANA is officially notified of TZ changes, so users could understand this is the result of their government changes, and notification processes, it is not a "defect" in how IANA or vendors roll out these updates. I do realize that sometimes “official” notifications seems to be that someone submitted a more formal government reference, instead of a news article. Maybe just an indicator of when the group is provided such official confirmation. Thanks for your consideration! Jan Harris SME: Globalization, Graphics, X11, Desktop, Commands/Auth AIX Development Support Organization - IBM O: Austin, TX 901:3i019 Ph: 1-512-286-5445 Jabber:23635445 E: janhar(a)us.ibm.com <mailto:janhar@us.ibm.com>

6 8

Inconsistencies between backward and backzone
by Benjamin Drung May 4, 2023

May 4, 2023

Hi, building tz with PACKRATDATA=backzone should result in time zones that only differ for dates before 1970. For dates after 1970 they should be identical to not building with PACKRATDATA=backzone (using backzone to create symlinks). But there are four (five if you include Pacific/Enderbury) time zones that has different UTC offset nowadays: * America/Ensenada differs from America/Tijuana * Asia/Kashgar differs from Asia/Urumqi * Atlantic/Jan_Mayen differs from Europe/Berlin * Europe/Tiraspol differs from Europe/Chisinau First investigation indicate that the timezones in backzone did not get the recent updates applied to them. -- Benjamin Drung Debian & Ubuntu Developer

2 3

Introduce Etc/UTC+x timezones?
by Benjamin Drung May 4, 2023

May 4, 2023

Hi, If people are aware of timezones, they often know UTC and their offsets (e.g. Europe/Berlin is UTC+2 summer). But they are probably not aware that the Etc/GMT offsets are inverted (e.g. you have to select Etc/GMT-2 for UTC+2). I was not aware of that and other people as well as the bugs in Ubuntu and Debian indicate (see https://launchpad.net/bugs/1325949 and https://bugs.debian.org/540305) What do you think about the idea of introducing Etc/UTC+x timezones that have the "correct" offset so that people can select fixed offsets more easily? So Etc/GMT-2 would be renamed to Etc/UTC+2 and Etc/GMT-2 would become a symlink to it (same for all other Etc/GMT+x and Etc/GMT-x timezones). -- Benjamin Drung Debian & Ubuntu Developer

16 31

DST changes for Egypt
by Eugen Cravciuc May 3, 2023

May 3, 2023

Hi. May you please update the values for the DST Egypt? Thank you https://www.timeanddate.com/time/change/egypt

2 1

offtime_r
by Dag-Erling Smørgrav April 26, 2023

April 26, 2023

The tzcode distribution includes a (non-standard and undocumented) offtime() function but no offtime_r() function, which seems like an oversight. The attached patch (relative to 2023c) adds it. Regards, Dag-Erling

2 3

Change Chile/Santiago DST
by Antonio Afranio Barbosa Martins April 26, 2023

April 26, 2023

Hi there, There is a issue with Daylight Saving Time (DST) for Chile/Santiago (South America). Based on some sites like https://www.timeanddate.com/time/zone/chile/santiago and https://www.bcn.cl/leychile/navegar?i=1179983&f=2022-08-13 (oficial Chile resolution) Correct time: Year Daily Time Change 2022 Sun, 3 Apr, 00:00 -1 hour (DST end) Sun, 11 Sep, 00:00 +1 hour (DST start) 2023 Sun, 2 Apr, 00:00 -1 hour (DST end) Sun, 3 Sep, 00:00 +1 hour (DST start) 2024 Sun, 7 Apr, 00:00 -1 hour (DST end) Sun, 8 Sep, 00:00 +1 hour (DST start) 2025 Sun, 6 Apr, 00:00 -1 hour (DST end) Sun, 7 Sep, 00:00 +1 hour (DST start) 2026 Sun, 5 Apr, 00:00 -1 hour (DST end) Sun, 6 Sep, 00:00 +1 hour (DST start) Descarga de Responsabilidad: Este mensaje contiene información confidencial y esta dirigido solamente al remitente especificado. Si usted no es el destinatario no debe tener acceso, distribuir ni copiar este e-mail. Notifique por favor al remitente inmediatamente si usted ha recibido este mensaje por error y eliminelo de su sistema. La transmisión del e-mail no se puede garantizar que sea segura, sin errores o como que la información podría ser interceptada, alterada, perdida, destruida, llegar atrasado, incompleto o contener virus, por lo tanto el remitente no acepta la responsabilidad por ningunos de los errores u omisiones en el contenido de este mensaje, que se presentan como resultado de la transmisión del e-mail. Si la verificación se requiere, por favor solicite una versión impresa. Disclaimer: This message contains confidential information and is intended only for recipient specified. If you are not recipient you should not disseminate, distribute or copy this e-mail. Please notify to sender immediately if you have received this message by mistake and delete this from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The receptor therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version.

2 2

Comments
by Arthur David Olson April 24, 2023

April 24, 2023

Fun fact: the time zone database is 80% comments by volume. @dashdashado

7 8

Mexico timezones
by Var Nazari April 10, 2023

April 10, 2023

Hello, Mexico has recently abolished daylight savings except for where they border with the United States. I believe the timezone database is now inaccurate because it should not be showing CDT for most of the country any longer and should be CST instead. It seems like this was addressed in release notes for the tzdb version 2022f and 2022g but I'm not sure that the correct changes were applied. Could you verify/explain why the timezones in Mexico are still recorded as CDT? Is this a mistake? Thank you

3 5

Changing 24:00 to 0:00 where possible
by Jacob Pratt April 5, 2023

April 5, 2023

While writing a parser for tzdb files, I noticed that some rules are for a given date at 24:00, rather than the following day at 0:00. While in some cases this is unavoidable (Egypt), in others there is no reason this is necessary (Belize). I think it would be reasonable to change 24:00 to 0:00 where possible, incrementing the day, day of week, and month as appropriate. This would reduce the need for special casing values to those that have a technical reason. Jacob Pratt

8 12

Error in the "America/Santiago" timezone for one week of September 2022
by Javier Ayala March 31, 2023

March 31, 2023

Hello, There is an error in the 'America/Santiago' timezone. The week between September 4th, 2022 and September 10th, 2022 should have the offset of -4.0, but it currently shows -3.0. This error occurred due to the 2022 Chilean national plebiscite <https://en.wikipedia.org/wiki/2022_Chilean_national_plebiscite>, which caused the government to postpone the scheduled time change by one week, from September 3rd to September 10th. Sources: - Decree in Chile's Official Gazette: https://www.diariooficial.interior.gob.cl/publicaciones/2022/08/13/43327/01… - News published in Chile's government website: https://www.gob.cl/noticias/ministerio-del-interior-informa-respecto-al-cam… Greetings, Javier Ayala

2 1

(no subject)
by Jack Bakaev March 29, 2023

March 29, 2023

Hello, Lebanon decided to postpone the DST till end of April instead of march 25-26 TZ complied then the cabinet of Ministers in Lebanon decided yesterday March 27 to revert to DST during the night of March 29-30. please do not revert Lebanon DST back to March 25-26! this will cause problems for those who who already complied with the postponement please revert to DST during the night of March 29-30. Jack Bakaev Internet Society - Lebanon Chapter Chapter Secretary

2 1

Re: [tz] [PROPOSED 2/2] Fix comments on Lebanon this week
by Paige Tummons March 29, 2023

March 29, 2023

Hi Paul, I'm reaching out regarding your request for comments<https://mm.icann.org/pipermail/tz/2023-March/032833.html> on the proposal to revert back to 2023a instead of updating 2023c to reflect the Lebanon DST change of 30 March. I've been working closely with medical centers in Lebanon to ensure that their healthcare systems are in continuous legal compliance with the government directives. We have been in close communication with Lebanese government authorities who legally consider the spring forward event to be on 30 March (with the jump being from 11:59:59 PM on 29 March to 01:00:00 AM on 30 March). We are strongly urging you to reflect this update in the 2023c file, to avoid the published tzdata file being in direct conflict with the government directive of the spring DST event in Lebanon happening on 30 March. The Prime Minister met with the cabinet yesterday, and together they agreed that Lebanon DST happens on the 30th of March. No government authorities consider the 26 March 2023 event to be the "true" DST time for Lebanon. Thanks, Paige Tummons

3 2

[tz-announce] 2023c release of tz code and data available
by Paul Eggert via tz-announce March 28, 2023

March 28, 2023

The 2023c release of the tz code and data is available. This release's code and data are identical to 2023a. In other words, this release reverts all changes made in 2023b other than commentary, as that appears to be the best of a bad set of short-notice choices for modeling this week's daylight saving chaos in Lebanon. (Thanks to Rany Hany for the heads-up about the government's announcement this week.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2023c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2023c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2023c.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit ddb8cf09d54ecc486ed6665edcdd642abccd4eef dated 2023-03-28 12:42:14 -0700 and tagged '2023c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: fa18bae9c0e7c061bc9d5f5f2eb9967f0e4ddb2baafdee9887fa30cd0c60f4aa6f21eacffb17df0d59d26ff54d08c5dcefa98159309eba497e86443624913a82 tzcode2023c.tar.gz 608bd286ebcbd0004cfdc1da183273f08aff61f90c8867661154453d77a05d421e4c46ad6d066a1fe2e87d5c82ec0f1c0224667a3b35f3180a3eb7f6ff84cbf5 tzdata2023c.tar.gz b59dbfc598b98f325797ff587bd2e8b27aadc52924eeb0b26cd18cdaca56224c436a20950bc73de9b9b46e98d640a24d8cb797a8f49ada15ea2f42a70a6efe22 tzdb-2023c.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQjQ8MACgkQ7ZfpDmKq fjTp4BAAvitWlH49WQ+Cfs//1bBy7ifW1I5PNXSZFIDSNsZUGhrXOkZ/b6l3jAEF Z76GL7PQb5d/QHdKAIYeDheGnGf/8Wh4PFGzBkiyZgEdeZk6QLtE1n71Fu1x7gca IQOmVTzwVAf9f+fbizsaTarqg30TnPzUsuHiljInOaV8GkTt0VUkIZ5LeH09kdpY Rq6BIiehGikkBLyvCpyCTGZ4H8IKgR0GMkIHWQwj0mw/WROnT+xAfzTUrtD7zJK2 5+Ek2kj0UDB9DbprIkCZyh56W1OZ4m5OuAd9wHdx1ZOPfE6jq0lm+2B2kX4759mQ U66wyATu1qqqlc/2HUe464SWCyNTEDGbCCygfryInKd9Y+QORhK9yOsDfskVcGgX qTE2U20YzMqHP34fgTUsOC+mQ9e+qR1CvnCGAv3y1wpUIj1r9Opq7cI1uCvVE6xn nJhU1oE+z4HjhT2TZSS+gVM8D6p+z096sOkRnFg+mIh7XzSYYSFRojcGLnSAkg+o K68yPfXPu0subUGi5dH1XLQQYM0v0sqCATu5jKwU4YyyHoUuWDi9mooReAkSaj+y KON+VuYMRZZfJqzdc0HcXUsqlY/nK6/INRbtgvEKlMRLBn5oGbWIRnlyQvJA814v fsaewl80tRZAtXs/hwHrSGX1vxMkMaaDk5frG9BG/EkupBZa/rk= =fwRN -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQjQ8MACgkQ7ZfpDmKq fjScAg/+LKVw3MFKXvXhDAJX9FPL+ZtvFc+XCwkAxylFA8rrLYjNTo+X7vdyu/AV 1YSkQFqPrPJrVMlffRm/NaQI59vOhkIQZ4Ingd0IFzfHIJMSMVU1C359mpUnxgce XLLUA12+Mjo3SEO/QYOZLhkpvzoJ2loPdgAUtraysunZdgYVdOubd8EpbWtZ/d9u cdKJriVWaHwcmEPXmZOcAhjTA2immhIrAd4G1FzuHFJNjdjIzJyXzxATWEk3mQ0z ZOQcpWGzf50OL9Atri4e8Nm4mXjguQHRebfYv8QVHAvxcdjGFc5yqvVrwGaNLGtV oadxHA3J/hmWS7mg7/pYDKabTNeoXrXWEzY8VXRbPnfvtbUXh9g4t9JDlgocHpQQ wAC3Hb/mvMFON68aCPWQeHxcHXOrAm2KHlGblJA9iI364S6v3iK7gd16lzZSbuTy G8jAt7YUilZxyIIV0GVMjQD9oG6bVm6ApccVVIBPHqlW1J09ON0koWRiNGqdbr8F BTh3ORBCo0qU+BvYF6mL9SCIrbGUvr4NdwY9aKaB04HPZz244fD2kLPt1z5v+7K6 cQrhdVQ6CqejhlJXRm4cQdeEzJhgxw+cFc256e8WpoofVu5rDws2d2KQZkqHGiFH A5jSKg2PWfZcqPoTdRg19DlUUdDBH8xybXzK5ExjHdDDO7KInGU= =XC0E -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQjQ8QACgkQ7ZfpDmKq fjS96g//dxNELnczZASWUk7n+EJ5EbMjamjOOAde6r/Mpy/71DLg0AatISKt+Ph+ 7lAVzQRip6o4mZNZb9PZ6yP3r1rYKUymaOahtiwv5oC2lSmm2jCMRlFslHJ/feQc czOfCfd7ggpmg95Iqx81WYfc2lSbXzNArpvqBEjApqtkOLbpJ7A7s2JFn7o3lnD2 E1gMeiIbM4doq2Dfqzc3sJ2kyn/zmsA2g/HO64DZ9RUiDJlbOAZctIAfDiSkHE8q MTdSIVlKrOXDzmzvN1YMXyIPbo4ZaFCjvSZ5xbEpu8nf1IrLq0WqkU41T+4cq3zD Vq0NHrADU49npWh1qn/PTJunln6I6BHIXzyDAAZL+Ij1lcplRh/ZdszZBxU267Qx 6rvEqeea1jQPEKS2/x9aMSWk4mwooB1pYHjnpgS+ZP1CLHtrWVtf5zU4Z2sODWBd p1otOWWgR1nq7b4qc0OZwwVzuJN8rtptEf0PuxgKZnLLoVmgEpU5WxA5FjhTsJmm 1nbv676DfIN31NOfSGcP12Lcp2KjZ2Cfj++zmQruTlZcjpWYEJiRjiecqELBWo7S jw96jrEUQi6mVn6jhzV0Sxdiig9M0hmzMj0bcx2BvldbUFCbZscAproR9fHeqpZM Q4F6QphFyP5Y3kBKARZZ3HmM6Kc5ZWkG6WzLeTkTdcxqHZLrp8c= =YTzD -----END PGP SIGNATURE-----

1 0