February 2019 - tz - lists.iana.org

proposed time zone package changes (Samoa, Factory, et al.)
by Arthur David Olson Aug. 28, 2019

Aug. 28, 2019

Below find proposed time zone package changes; the executive summary: * Makefile Change LOCALTIME default from "Factory" to "GMT"; do not compile "factory" file (but keep it in the distribution). * Theory Remove reference to "Factory" zone. * australasia Change end of DST in Samoa in 2011 from 2011-04-03 0:00 to 2011-04-03 1:00 (thanks to Raymond Hughes for a reference). * localtime.c Initialize ttinfo structures filled by tzparse (thanks to Ravindra for reporting a valgrind warning). * zic.c Fix generation of POSIX strings for zones with rules using "weekday<=n" forms of dates (thanks to Lei Liu for finding the problem). Also, limit output for non-POSIX-specificable zones defined to follow the same rules every year. (Note that no zones of either of the above types appear in the distribution; these changes cater to add-on zones). If no problems are found, 2010n will appear on 2010-10-25. --ado diff -r -c old/Makefile new/Makefile *** old/Makefile Mon Sep 27 09:24:25 2010 --- new/Makefile Tue Oct 12 12:36:50 2010 *************** *** 1,5 **** # <pre> ! # @(#)Makefile 8.8 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)Makefile 8.9 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 12,18 **** # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= Factory # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, --- 12,18 ---- # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= GMT # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, *************** *** 262,269 **** DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera factory backward ! NDATA= systemv SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab --- 262,269 ---- DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward ! NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab diff -r -c old/Theory new/Theory *** old/Theory Mon Sep 27 09:24:25 2010 --- new/Theory Tue Oct 12 12:36:50 2010 *************** *** 1,4 **** ! @(#)Theory 8.4 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. --- 1,4 ---- ! @(#)Theory 8.5 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. *************** *** 287,294 **** See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', `EET' (see the file `europe'), ! and `Factory' (see the file `factory'). ----- Time zone abbreviations ----- --- 287,293 ---- See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', and `EET' (see the file `europe'). ----- Time zone abbreviations ----- diff -r -c old/australasia new/australasia *** old/australasia Mon Sep 27 09:24:27 2010 --- new/australasia Tue Oct 12 13:14:56 2010 *************** *** 1,5 **** # <pre> ! # @(#)australasia 8.18 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)australasia 8.19 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 487,497 **** # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 -11:00 - WST # Solomon Is --- 487,507 ---- # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> + # From Raymond Hughes (2010-10-07): + # Please see + # <a href="http://www.mcil.gov.ws"> + # http://www.mcil.gov.ws + # </a>, + # the Ministry of Commerce, Industry and Labour (sideframe) "Last Sunday + # September 2010 (26/09/10) - adjust clocks forward from 12:00 midnight + # to 01:00am and First Sunday April 2011 (03/04/11) - adjust clocks + # backwards from 1:00am to 12:00am" + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 1:00 -11:00 - WST # Solomon Is diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Mon Sep 27 09:24:26 2010 --- new/localtime.c Tue Oct 12 12:36:51 2010 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.14"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.15"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 914,919 **** --- 914,920 ---- register unsigned char * typep; register char * cp; register int load_result; + static struct ttinfo zttinfo; INITIALIZE(dstname); stdname = name; *************** *** 986,991 **** --- 987,993 ---- /* ** Two transitions per year, from EPOCH_YEAR forward. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -dstoffset; sp->ttis[0].tt_isdst = 1; sp->ttis[0].tt_abbrind = stdlen + 1; *************** *** 1099,1106 **** } /* ** Finally, fill in ttis. - ** ttisstd and ttisgmt need not be handled. */ sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; --- 1101,1108 ---- } /* ** Finally, fill in ttis. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; *************** *** 1113,1118 **** --- 1115,1121 ---- dstlen = 0; sp->typecnt = 1; /* only standard time */ sp->timecnt = 0; + sp->ttis[0] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_abbrind = 0; diff -r -c old/zic.c new/zic.c *** old/zic.c Mon Sep 27 09:24:26 2010 --- new/zic.c Tue Oct 12 13:37:29 2010 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.22"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.24"; #include "private.h" #include "locale.h" *************** *** 1881,1896 **** register int week; if (rp->r_dycode == DC_DOWGEQ) { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", --- 1881,1896 ---- register int week; if (rp->r_dycode == DC_DOWGEQ) { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) return -1; + week = 1 + rp->r_dayofmonth / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) return -1; + week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", *************** *** 2018,2023 **** --- 2018,2024 ---- register char * envvar; register int max_abbr_len; register int max_envvar_len; + register int prodstic; /* all rules are min to max */ max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; *************** *** 2032,2037 **** --- 2033,2039 ---- timecnt = 0; typecnt = 0; charcnt = 0; + prodstic = zonecount == 1; /* ** Thanks to Earl Chew ** for noting the need to unconditionally initialize startttisstd. *************** *** 2053,2058 **** --- 2055,2062 ---- updateminmax(rp->r_loyear); if (rp->r_hiwasnum) updateminmax(rp->r_hiyear); + if (rp->r_lowasnum || rp->r_hiwasnum) + prodstic = FALSE; } } /* *************** *** 2075,2080 **** --- 2079,2094 ---- if (max_year <= INT_MAX - YEARSPERREPEAT) max_year += YEARSPERREPEAT; else max_year = INT_MAX; + /* + ** Regardless of any of the above, + ** for a "proDSTic" zone which specifies that its rules + ** always have and always will be in effect, + ** we only need one cycle to define the zone. + */ + if (prodstic) { + min_year = 1900; + max_year = min_year + YEARSPERREPEAT; + } } /* ** For the benefit of older systems,

5 6

Hong Kong Time history
by P Chan May 31, 2019

May 31, 2019

*According to the Hong Kong Daylight-Saving Regulations, 1941, the 1941 spring-forward transition was at 03:00. http://sunzi.lib.hku.hk/hkgro/view/g1941/304271.pdf http://sunzi.lib.hku.hk/hkgro/view/g1941/305516.pdf *According to some articles from South China Morning Post, +08 was resumed on 1945-11-18 at 02:00. https://i.imgur.com/M2IsZ3c.png https://i.imgur.com/iOPqrVo.png https://i.imgur.com/fffcGDs.png *Some newspapers published on said the 1946 spring-forward transition was on 04-21 at 00:00. The Kung Sheung Evening News 1946-04-20 (Chinese) https://i.imgur.com/ZSzent0.png https://mmis.hkpl.gov.hk///c/portal/cover?c=QF757YsWv5%2FH7zGe%2FKF%2BFLYsu… p.4 The Kung Sheung Daily News 1946-04-21 (Chinese) https://i.imgur.com/7ecmRlcm.png https://mmis.hkpl.gov.hk///c/portal/cover?c=QF757YsWv5%2BQBGt1%2BwUj5qG2Gqt… p.4 *According to the Summer Time Ordinance (1946), the fallback transitions between 1946 and 1952 were at 03:30 Standard Time (+08) http://oelawhk.lib.hku.hk/archive/files/bb74b06a74d5294620a15de560ab33c6.pdf *Some other laws and regulations related to DST from 1953 to 1979 Summer Time Ordinance 1953 https://i.imgur.com/IOlJMav.jpg Summer Time (Amendment) Ordinance 1965 https://i.imgur.com/8rofeLa.jpg Interpretation and General Clauses Ordinance (1966) https://i.imgur.com/joy3msj.jpg Emergency (Summer Time) Regulation 1973 https://i.imgur.com/OpRWrKz.jpg Interpretation and General Clauses (Amendment) Ordinance 1977 https://i.imgur.com/RaNqnc4.jpg Resolution of the Legislative Council passed on 9 May 1979 https://www.legco.gov.hk/yr78-79/english/lc_sitg/hansard/h790509.pdf#page=39 P Chan

4 7

Fwd: Historical timezone data for Bonin Islands (Ogasawara)
by Phake Nick May 29, 2019

May 29, 2019

Hello all, I have recently received some new information about timezone history of Bonin Islands, Japan as detailed in the attached message. Because their last time change to return to Japanese time when they return to Japanese rule was right before 1970, it mean per the current tz database rule, the information doesn't warrant creation of a new timezone for Bonin Islands itself and is thus as an anecdotal note for interest purpose only. However, in the attached link, it described some special timekeeping phenomenon regarding Marcus island, another remote island currently owned by Japanese in the same administrative unit as Bonin Islands. Many reports claim that the American coastal guard on the American quarter of the island use its own coastal guard time, and most sources describe the time as UTC+11, being two hours faster than JST used by some Japanese personnel on the island. Some sites describe it as same as Wake Island/Guam time although it would be incorrect to be same as Guam. And then in a few Japanese governmental report from 1980s (from National Institute of Information and Communications Technology) regarding the construction of VLBI facility on the Marcus Island, it claimed that there're three time standard being used on the island at the time which include not just JST (UTC+9) or [US]CG time (UTC+11) but also a JMSDF time (UTC+10) (Japan Maritime Self-Defense Force). Unfortunately there are no other sources that mentioned such time and there are also no information on things like how the tine was used. ---------- Forwarded message --------- From: Wakaba Date: 2019-1-28 Mon 13:48 Subject: Re: Question related to the page 昭和のサマータイム on suikawiki To: Phake Nick >> Hello, I see that there're a lot of information about DST at the time in Japan on Suikawiki, but a special area that's not mentioned in the page os Ogasawara 小笠原諸島 (Bonin Islands) which seems to have its own different history of governance. Do you know where can information related to timezone of the islands can be found? > Unfortunately we have no reliable source on time in US-controlled Ogasawara Islands at the moment. It turns out that National Diet Library of Japan has several reports by Japanese Government officers that describe the time used in islands when they visited there. According to them (and other sources such as newspapers), standard time UTC + 10 (JST + 1) and DST UTC + 11 (JST + 2) was used until its return to Japan at 1968-06-26 00:00 JST. The exact periods of DST are still unknown. I guessed Guam, Mariana, and Bonin and Marcus districts might have synchronized their DST periods, but reports imply they had their own decisions, i.e. there were three or more different time zones. Details: https://wiki.suikawiki.org/n/%E5%B0%8F%E7%AC%A0%E5%8E%9F%E8%AB%B8%E5%B3%B6%…

2 1

Decree for Chile DST change
by Juan Correa May 17, 2019

May 17, 2019

I couldn't find the decree for the chilean DST change until today (even when it was published on November 23th on the Official Gazette, I searched for it on december 2018 with no avail) http://www.diariooficial.interior.gob.cl/publicaciones/2018/11/23/42212/01/… The only extra bit of information is that America/Punta_Arenas is confirmed to not change until 2022 -- Juan Correa Poblete PS Labs (http://www.pslabs.cl)

2 1

Big tech warns of 'Japan's millennium bug' ahead of Akihito's abdication
by Martin Burnicki April 30, 2019

April 30, 2019

Don't know if this has already been known, or if it's really relevant for this list, but ... "Big tech warns of 'Japan's millennium bug' ahead of Akihito's abdication" https://www.theguardian.com/technology/2018/jul/25/big-tech-warns-japan-mil… Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki(a)meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy

7 9

Brazilian state of Goiás may abolish DST
by World Time Zone April 26, 2019

April 26, 2019

According to some news Brazilian state of Goiás may abolish DST: "The Energy and Mines Commission of the House of Representatives approved a Legislative Decree that suspends daylight saving time in Goiás." http://www.infomoney.com.br/minhas-financas/consumo/noticia/7061178/comissa… Also, ".... this year the federal government even considered not implementing daylight saving time, but left the decision to 2018." Alexander Krivenyshev https://www.WorldTimeZone.com

5 5

Please remove tzdata2018f
by Ankur Rana March 11, 2019

March 11, 2019

Hello Paul/Team, While doing tzdata upgrade to version 2018f, we found below issue. java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:226) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:222) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:643) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) ... 5 more We further found that the issue was addressed in version 2018g. To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site? [Ericsson]<http://www.ericsson.com/> ANKUR RANA Senior Software Developer Bussiness Area Digital Services - Development Unit Ericsson Block A, King Canyon "ASF Insignia" THE IT/ITES SEZ, Faridabad Road, Gawal Pahari, Gurgaon 122003, India Phone +91-124-3088600 Mobile +91-9811264594 ankur.rana(a)ericsson.com www.ericsson.com [http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign> Legal entity: Ericsson India Global Services Pvt Ltd, registered office in Gurgaon. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

8 14

tzdb timezone names/identifiers and links (was: Add new timezone for Hanoi Capital, Vietnam)
by Hans-Joerg Happel March 1, 2019

March 1, 2019

Dear all, as a follow-up to the "Hanoi" thread, I've some questions regarding tzdb policies. As it is a slightly separate / more general point, I'll single that thread out from the initial "Hanoi" discussion. In particular, I'd like to understand the background of the following item (taken from https://data.iana.org/time-zones/theory.html#naming) >There should typically be at least one name for each ISO 3166-1 <https://en.wikipedia.org/wiki/ISO_3166-1> officially >assigned two-letter code for an inhabited country or territory. I initially thought this would be the reason for the "Links" of "Asia/Phnom_Penh" and "Asia/Vientiane" to "Asia/Bangkok". However, latest discussion in the "Hanoi" thread rather attributed these two aliases to backwards compatibility after prior data was moved to the backzone file. I'd assume the quoted "ISO 3166-1"-based policy could make sense for two reasons: a) Congruence of ids and decision-making bodies (i.e., countries/governments): In contrast to data stored using "Asia/Bangkok", systems/data using the "Asia/Phnom_Penh" name/link/alias/id would not need to change/re-configure in case the government of Cambodia decides to deviate from "Asia/Bangkok" at some time b) Politically: Even if tzdb names might not be intended as "names", they do surface from time to time, as with configuring time zones on a machine [1], or by applications just passing through tzdb names. I can somehow understand that this is not fully satisfactory in the Vietnam/Hanoi case right now (see below). While it is neither the intention nor the concern of tzdb to deal with this, one can argue that in practice, there is still clearly a practical impact of tzdb names/ids. So any information on the rationale for the above-quoted rule is appreciated. Also, I see there are recommendations for implementers regarding localization (e.g., reference to Unicode CLDR), but I could not find recommendations concerning the usage of tzdb names/ids/links/aliases - which, in my understanding, will be the String persisted by most applications in the end? If so, setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation. In case Vietnam would deviate from "Asia/Bangkok" in the future (by either Thai or Vietnamese decision), legacy data might need to be change to an "Asia/Hanoi" identifier. I'd be interested in pointers if this aspect was ever discussed here or is considered relevant at all. Thanks and best, Hans-Joerg ps.: as for the Vietnam case, note that the "displayName()" property in Java shows "Indochina" for most zones under discussion [2] Also Unicode CLDR translations look tricky in this case (http://st.unicode.org/cldr-apps/survey?_=en&x=r_zones) [1] E.g. https://askubuntu.com/questions/323131/setting-timezone-from-terminal/323163 points out the two options of |sudo cp /usr/share/zoneinfo/Asia/Bangkok /etc/localtime| (explicit!) or |tzselect | ..yielding the following dialogue: Please select a country whose clocks agree with yours. 1) Afghanistan 18) Israel 35) Palestine ......... 15) Indonesia 32) Nepal 49) Vietnam 16) Iran 33) Oman 50) Yemen 17) Iraq 34) Pakistan #? 49 Please select one of the following time zone regions. 1) Indochina (most areas) 2) Vietnam (south) ...which looks better, but is also not ideal from a user point-of-view... [2] Java TimeZone.getDisplayName() output for EN/DE/FR locale (Oracle JDK 1.8.0_191): Asia/Bangkok / Indochina Time Asia/Bangkok / Indochina Zeit Asia/Bangkok / Heure d'Indochine Asia/Ho_Chi_Minh / Indochina Time Asia/Ho_Chi_Minh / Indochina Zeit Asia/Ho_Chi_Minh / Heure d'Indochine Asia/Phnom_Penh / Indochina Time Asia/Phnom_Penh / Indochina Zeit Asia/Phnom_Penh / Heure d'Indochine Asia/Saigon / Indochina Time Asia/Saigon / Indochina Zeit Asia/Saigon / Heure d'Indochine Asia/Vientiane / Indochina Time Asia/Vientiane / Indochina Zeit Asia/Vientiane / Heure d'Indochine VST / Indochina Time VST / Indochina Zeit VST / Heure d'Indochine -- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/> Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142

22 105

adding LLT to the Time Zone Database
by filip Feb. 26, 2019

Feb. 26, 2019

Greetings everyone! I was told that this is the community/staff of this mailing list that i should poke if i want to add an entry into the Time Zone Database. I am working at the company Firo Solutions and we have implemented LLT(liberland time) into our systems and it all works great. However, We want to add support for LLT into several larger programming libraries some maintainers have told us that we need to get LLT/Liberland Time into your database in order to get it officially supported. Liberland is a pretty new country(2015) and the timezone is UTC+1(same as serbian). Could it be added to your database? It shouldnt be so hard i think and in iana i trust! Take Care and have a good week! Sincerely Filip

3 3

Summary document for 2/5/2019 CalConnect event
by Arthur David Olson Feb. 26, 2019

Feb. 26, 2019

A summary document for the 2/5/2019 CalConnect event is now available at... http://lists.calconnect.org/pipermail/timezonediscuss-l-calconnect.org/2019… @dashdashado

2 1