- tz - lists.iana.org

vlog on personal timezones
by Zefram Nov. 8, 2017

Nov. 8, 2017

Here's a vlog that may be of interest to people on this list. It's CGP Grey, whose "Daylight Saving Time Explained" video has previously been mentioned here, taking a three-day trip to Las Vegas (America/Los_Angeles) from Britain (Europe/London). Rather than live with the jet lag, he decides to keep his circadian rhythm on London time throughout the trip. As he comments, the 24-hour culture of Las Vegas is particularly amenable to maintaining a non-local timezone. https://www.youtube.com/watch?v=f-mHLBD64HM -zefram

2 1

[PROPOSED] Be more consistent about UT vs UTC
by Paul Eggert Nov. 8, 2017

Nov. 8, 2017

* NEWS, africa, asia, australasia, europe, localtime.c: * newctime.3, newtzset.3, northamerica, southamerica, theory.html: * tz-link.htm, tzselect.ksh, zdump.c, zic.8, zic.c: Be more consistent about using "UT" instead of "UTC" when talking about timestamps that might predate the introduction of UTC. * tzselect.ksh: Use AEST instead of the (obsolescent) abbreviation GST when talking about UT offsets. --- NEWS | 29 +++++++++++++++++------------ africa | 2 +- asia | 14 +++++++------- australasia | 4 ++-- europe | 6 +++--- localtime.c | 2 +- newctime.3 | 2 +- newtzset.3 | 20 ++++++++++---------- northamerica | 2 +- southamerica | 4 ++-- theory.html | 6 +++--- tz-link.htm | 14 +++++++------- tzselect.ksh | 5 +++-- zdump.c | 14 +++++++------- zic.8 | 4 ++-- zic.c | 2 +- 16 files changed, 68 insertions(+), 62 deletions(-) diff --git a/NEWS b/NEWS index de81afc..2254650 100644 --- a/NEWS +++ b/NEWS @@ -33,6 +33,11 @@ Unreleased, experimental changes that have snprintf and use pre-C99 compilers. (Problem reported by Jon Skeet.) + Changes to code + + Diagnostis and commentary are now more careful about + distinguishing UT from UTC. + Release 2017c - 2017-10-20 14:49:34 -0700 @@ -929,8 +934,8 @@ Release 2015f - 2015-08-10 18:06:56 -0700 (Thanks to Jon Skeet and Arthur David Olson.) Constraints on simultaneity are now documented. - The two characters '%z' in a zone format now stand for the UTC - offset, e.g., '-07' for seven hours behind UTC and '+0530' for + The two characters '%z' in a zone format now stand for the UT + offset, e.g., '-07' for seven hours behind UT and '+0530' for five hours and thirty minutes ahead. This better supports time zone abbreviations conforming to POSIX.1-2001 and later. @@ -1053,13 +1058,13 @@ Release 2015c - 2015-04-11 08:55:55 -0700 The spring 1988 transition was 1988-10-09, not 1988-10-02. The fall 1990 transition was 1990-03-11, not 1990-03-18. - Assume no UTC offset change for Pacific/Easter on 1890-01-01, + Assume no UT offset change for Pacific/Easter on 1890-01-01, and omit all transitions on Pacific/Easter from 1942 through 1946 since we have no data suggesting that they existed. One more zone has been turned into a link, as it differed from an existing zone only for older time stamps. As usual, - this change affects UTC offsets in pre-1970 time stamps only. + this change affects UT offsets in pre-1970 time stamps only. The zone's old contents have been moved to the 'backzone' file. The affected zone is America/Montreal. @@ -1089,7 +1094,7 @@ Release 2015b - 2015-03-19 23:28:11 -0700 Some more zones have been turned into links, when they differed from existing zones only for older time stamps. As usual, - these changes affect UTC offsets in pre-1970 time stamps only. + these changes affect UT offsets in pre-1970 time stamps only. Their old contents have been moved to the 'backzone' file. The affected zones are: America/Antigua, America/Cayman, Pacific/Midway, and Pacific/Saipan. @@ -1141,7 +1146,7 @@ Release 2015a - 2015-01-29 22:35:20 -0800 Some more zones have been turned into links, when they differed from existing zones only for older time stamps. As usual, - these changes affect UTC offsets in pre-1970 time stamps only. + these changes affect UT offsets in pre-1970 time stamps only. Their old contents have been moved to the 'backzone' file. The affected zones are: Asia/Aden, Asia/Bahrain, Asia/Kuwait, and Asia/Muscat. @@ -1188,7 +1193,7 @@ Release 2014j - 2014-11-10 17:37:11 -0800 Some more zones have been turned into links, when they differed from existing zones only for older time stamps. As usual, - these changes affect UTC offsets in pre-1970 time stamps only. + these changes affect UT offsets in pre-1970 time stamps only. Their old contents have been moved to the 'backzone' file. The affected zones are: Africa/Addis_Ababa, Africa/Asmara, Africa/Dar_es_Salaam, Africa/Djibouti, Africa/Kampala, @@ -1278,7 +1283,7 @@ Release 2014h - 2014-09-25 18:59:03 -0700 Some more zones have been turned into links, when they differed from existing zones only for older timestamps. As usual, - these changes affect UTC offsets in pre-1970 timestamps only. + these changes affect UT offsets in pre-1970 timestamps only. Their old contents have been moved to the 'backzone' file. The affected zones are: Africa/Blantyre, Africa/Bujumbura, Africa/Gaborone, Africa/Harare, Africa/Kigali, Africa/Lubumbashi, @@ -1363,7 +1368,7 @@ Release 2014g - 2014-08-28 12:31:23 -0700 Some more zones have been turned into links, when they differed from existing zones only for older timestamps. As usual, - these changes affect UTC offsets in pre-1970 timestamps only. + these changes affect UT offsets in pre-1970 timestamps only. Their old contents have been moved to the 'backzone' file. The affected zones are: Africa/Bangui, Africa/Brazzaville, Africa/Douala, Africa/Kinshasa, Africa/Libreville, Africa/Luanda, @@ -1513,7 +1518,7 @@ Release 2014f - 2014-08-05 17:42:36 -0700 standard and daylight saving time the abbreviations are AEST and AEDT instead of the former EST for both; similarly, ACST/ACDT, ACWST/ACWDT, and AWST/AWDT are now used instead of the former CST, CWST, and WST. - This change does not affect UTC offsets, only time zone abbreviations. + This change does not affect UT offsets, only time zone abbreviations. (Thanks to Rich Tibbett and many others.) Asia/Novokuznetsk shifts from NOVT to KRAT (remaining on UT +07) @@ -1550,8 +1555,8 @@ Release 2014f - 2014-08-05 17:42:36 -0700 Treindl sent helpful translations of two papers by Guo Qingsheng.) Some zones have been turned into links, when they differed from existing - zones only for older UTC offsets where data entries were likely invented. - These changes affect UTC offsets in pre-1970 timestamps only. This is + zones only for older UT offsets where data entries were likely invented. + These changes affect UT offsets in pre-1970 timestamps only. This is similar to the change in release 2013e, except this time for western Africa. The affected zones are: Africa/Bamako, Africa/Banjul, Africa/Conakry, Africa/Dakar, Africa/Freetown, Africa/Lome, diff --git a/africa b/africa index 3a60bc2..be44580 100644 --- a/africa +++ b/africa @@ -425,7 +425,7 @@ Link Africa/Nairobi Indian/Mayotte # # The Nautical Almanac for the Year 1970, p 264, is the source for -0:44:30. # -# In 1972 Liberia was the last country to switch from a UTC offset +# In 1972 Liberia was the last country to switch from a UT offset # that was not a multiple of 15 or 20 minutes. The 1972 change was on # 1972-01-07, according to an entry dated 1972-01-04 on p 330 of: # Presidential Papers: First year of the administration of diff --git a/asia b/asia index ac39af3..91076fd 100644 --- a/asia +++ b/asia @@ -50,7 +50,7 @@ # 9:00 KST KDT Korea when at +09 # 9:30 ACST Australian Central Standard Time # Otherwise, these tables typically use numeric abbreviations like +03 -# and +0330 for integer hour and minute UTC offsets. Although earlier +# and +0330 for integer hour and minute UT offsets. Although earlier # editions invented alphabetic time zone abbreviations for every # offset, this did not reflect common practice. # @@ -647,17 +647,17 @@ Zone Asia/Hong_Kong 7:36:42 - LMT 1904 Oct 30 # time", in which abolished the adoption of Western Standard Time in # western islands (listed above), which means the whole Japan # territory, including later occupations, adopt Japan Central Time -# (UTC+9). The adoption began on Oct 1, 1937. The original text can +# (UT+9). The adoption began on Oct 1, 1937. The original text can # be found on Wikisource: # https://ja.wikisource.org/wiki/明治二十八年勅令第百六十七號標準時ニ關スル件中改正ノ件 # -# That is, the time zone of Taipei switched to UTC+9 on Oct 1, 1937. +# That is, the time zone of Taipei switched to UT+9 on Oct 1, 1937. # From Yu-Cheng Chuang (2014-07-02): -# I've found more evidence about when the time zone was switched from UTC+9 -# back to UTC+8 after WW2. I believe it was on Sep 21, 1945. In a document +# I've found more evidence about when the time zone was switched from UT+9 +# back to UT+8 after WW2. I believe it was on Sep 21, 1945. In a document # during Japanese era [1] in which the officer told the staff to change time -# zone back to Western Standard Time (UTC+8) on Sep 21. And in another +# zone back to Western Standard Time (UT+8) on Sep 21. And in another # history page of National Cheng Kung University [2], on Sep 21 there is a # note "from today, switch back to Western Standard Time". From these two # materials, I believe that the time zone change happened on Sep 21. And @@ -1505,7 +1505,7 @@ Rule Japan 1950 1951 - May Sun>=1 2:00 1:00 D # # ...the Showa Emperor announced Ordinance No. 529 of Showa Year 12 ... which # means the whole Japan territory, including later occupations, adopt Japan -# Central Time (UTC+9). The adoption began on Oct 1, 1937. +# Central Time (UT+9). The adoption began on Oct 1, 1937. # https://ja.wikisource.org/wiki/明治二十八年勅令第百六十七號標準時ニ關スル件中改正ノ件 # Zone NAME GMTOFF RULES FORMAT [UNTIL] diff --git a/australasia b/australasia index 5f7c86d..9a968e4 100644 --- a/australasia +++ b/australasia @@ -683,8 +683,8 @@ Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct # Honiara # From Steffen Thorsen (2012-07-25) # ... we double checked by calling hotels and offices based in Tokelau asking # about the time there, and they all told a time that agrees with UTC+13.... -# Shanks says UTC-10 from 1901 [but] ... there is a good chance the change -# actually was to UTC-11 back then. +# Shanks says UT-10 from 1901 [but] ... there is a good chance the change +# actually was to UT-11 back then. # # From Paul Eggert (2012-07-25) # A Google Books snippet of Appendix to the Journals of the House of diff --git a/europe b/europe index cf6d7e4..7bca59b 100644 --- a/europe +++ b/europe @@ -2772,9 +2772,9 @@ Zone Asia/Omsk 4:53:30 - LMT 1919 Nov 14 # # https://regnum.ru/news/society/1957270.html # has some historical data for Altai Krai: -# before 1957: west part on UTC+6, east on UTC+7 -# after 1957: UTC+7 -# since 1995: UTC+6 +# before 1957: west part on UT+6, east on UT+7 +# after 1957: UT+7 +# since 1995: UT+6 # http://barnaul.rusplt.ru/index/pochemu_altajskij_kraj_okazalsja_v_neprivych… # confirms that and provides more details including 1995-05-28 transition date. diff --git a/localtime.c b/localtime.c index 2e1d621..9b8266a 100644 --- a/localtime.c +++ b/localtime.c @@ -1982,7 +1982,7 @@ time2sub(struct tm *const tmp, && ((BIGGEST (INT_FAST32_MIN, LONG_MIN) + yourtm.TM_GMTOFF) <= mytm.TM_GMTOFF)))) { - /* MYTM matches YOURTM except with the wrong UTC offset. + /* MYTM matches YOURTM except with the wrong UT offset. YOURTM.TM_GMTOFF is plausible, so try it instead. It's OK if YOURTM.TM_GMTOFF contains uninitialized data, since the guess gets checked. */ diff --git a/newctime.3 b/newctime.3 index 8b89935..b376ae1 100644 --- a/newctime.3 +++ b/newctime.3 @@ -191,7 +191,7 @@ extra initial argument specifying the time zone to be used for conversion. If .B zone -is null, UTC is used; otherwise, +is null, UT is used; otherwise, .B zone should be have been allocated by .I tzalloc diff --git a/newtzset.3 b/newtzset.3 index c3e22dc..beee20a 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -61,7 +61,7 @@ If the implied call to .B tzalloc fails, .I tzset -falls back on UTC. +falls back on Universal Time (UT). .PP If .B TZ @@ -74,7 +74,7 @@ in the system time conversion information directory, is used. If .B TZ is the empty string, -Universal Time (UT) is used, with the abbreviation "UTC" +UT is used, with the abbreviation "UTC" and without leap second correction; please see .IR newctime (3) for more about UT, UTC, and leap seconds. If @@ -256,22 +256,22 @@ extensions to POSIX. .TP .B EST5 stands for US Eastern Standard -Time (EST), 5 hours behind UTC, without daylight saving. +Time (EST), 5 hours behind UT, without daylight saving. .TP .B FJT\*-12FJST,M11.1.0,M1.3.4/75 stands for Fiji Time (FJT) and Fiji Summer Time (FJST), 12 hours ahead -of UTC, springing forward on November's first Sunday at 02:00, and +of UT, springing forward on November's first Sunday at 02:00, and falling back on January's third Thursday at 75:00 (i.e., 03:00 on the first Sunday on or after January 18). .TP .B IST\*-2IDT,M3.4.4/26,M10.5.0 stands for Israel Standard Time (IST) and Israel Daylight Time (IDT), -2 hours ahead of UTC, springing forward on March's fourth +2 hours ahead of UT, springing forward on March's fourth Thursday at 26:00 (i.e., 02:00 on the first Friday on or after March 23), and falling back on October's last Sunday at 02:00. .TP .B WART4WARST,J1/0,J365/25 -stands for Western Argentina Summer Time (WARST), 3 hours behind UTC. +stands for Western Argentina Summer Time (WARST), 3 hours behind UT. There is a dummy fall-back transition on December 31 at 25:00 daylight saving time (i.e., 24:00 standard time, equivalent to January 1 at 00:00 standard time), and a simultaneous spring-forward transition on @@ -282,9 +282,9 @@ is a placeholder. .TP .B WGT3WGST,M3.5.0/\*-2,M10.5.0/\*-1 stands for Western Greenland Time (WGT) and Western Greenland Summer -Time (WGST), 3 hours behind UTC, where clocks follow the EU rules of -springing forward on March's last Sunday at 01:00 UTC (\-02:00 local -time) and falling back on October's last Sunday at 01:00 UTC +Time (WGST), 3 hours behind UT, where clocks follow the EU rules of +springing forward on March's last Sunday at 01:00 UT (\-02:00 local +time) and falling back on October's last Sunday at 01:00 UT (\-01:00 local time). .PP If no @@ -297,7 +297,7 @@ by the file .B posixrules in the system time conversion information directory are used, with the -standard and summer time offsets from UTC replaced by those specified by +standard and summer time offsets from UT replaced by those specified by the .I offset values in diff --git a/northamerica b/northamerica index e5d3eca..505300a 100644 --- a/northamerica +++ b/northamerica @@ -1896,7 +1896,7 @@ Zone America/Edmonton -7:33:52 - LMT 1906 Sep # manager of the Creston & District Museum. The article was written in May 2009. # http://www.ilovecreston.com/?p=articles&t=spec&ar=260 # According to the article, Creston has not changed its clocks since June 1918. -# i.e. Creston has been stuck on UTC-7 for 93 years. +# i.e. Creston has been stuck on UT-7 for 93 years. # Dawson Creek, on the other hand, changed its clocks as recently as April 1972. # Unfortunately the exact date for the time change in June 1918 remains diff --git a/southamerica b/southamerica index bbae226..e0b3265 100644 --- a/southamerica +++ b/southamerica @@ -25,7 +25,7 @@ # https://www.jstor.org/stable/1774359 # # These tables use numeric abbreviations like -03 and -0330 for -# integer hour and minute UTC offsets. Although earlier editions used +# integer hour and minute UT offsets. Although earlier editions used # alphabetic time zone abbreviations, these abbreviations were # invented and did not reflect common practice. @@ -1068,7 +1068,7 @@ Zone America/Rio_Branco -4:31:12 - LMT 1914 # From Paul Eggert (2015-04-03): # Shanks & Pottenger says America/Santiago introduced standard time in -# 1890 and rounds its UTC offset to 70W40; guess that in practice this +# 1890 and rounds its UT offset to 70W40; guess that in practice this # was the same offset as in 1916-1919. It also says Pacific/Easter # standardized on 109W22 in 1890; assume this didn't change the clocks. # diff --git a/theory.html b/theory.html index 965135d..3e686a0 100644 --- a/theory.html +++ b/theory.html @@ -598,7 +598,7 @@ POSIX has the following properties and limitations. and daylight saving time (DST) zone names. Starting with POSIX.1-2001, <var>std</var> and <var>dst</var> may also be - in a quoted form like '<code><UTC+10></code>'; this allows + in a quoted form like '<code><+09></code>'; this allows "<code>+</code>" and "<code>-</code>" in the names. </dd> <dt><var>offset</var></dt><dd> @@ -646,7 +646,7 @@ POSIX has the following properties and limitations. </dd> </dl> Here is an example POSIX TZ string for New Zealand after 2007. - It says that standard time (NZST) is 12 hours ahead of UTC, + It says that standard time (NZST) is 12 hours ahead of UT, and that daylight saving time (NZDT) is observed from September's last Sunday at 02:00 until April's first Sunday at 03:00: @@ -678,7 +678,7 @@ POSIX has the following properties and limitations. applications that an administrator wants used only at certain times – without regard to whether the user has fiddled the TZ environment - variable. While an administrator can "do everything in UTC" to get + variable. While an administrator can "do everything in UT" to get around the problem, doing so is inconvenient and precludes handling daylight saving time shifts - as might be required to limit phone calls to off-peak hours.) diff --git a/tz-link.htm b/tz-link.htm index 835df40..2a8a486 100644 --- a/tz-link.htm +++ b/tz-link.htm @@ -432,7 +432,7 @@ It is freely available under the <abbr>LGPL</abbr>.</li> implementation of a binary file reader. It is freely available under the Apache License.</li> <li><a href="https://github.com/google/cctz">CCTZ</a> is a simple C++ -library that translates between <abbr>UTC</abbr> and civil time and +library that translates between <abbr>UT</abbr> and civil time and can read binary files. It is freely available under the Apache License.</li> <li><a href="http://bmsi.com/java/#TZ">ZoneInfo.java</a> @@ -660,7 +660,7 @@ world time zone boundaries distributed under the href="https://en.wikipedia.org/wiki/Territorial_waters">territorial waters</a> of any nation uses that nation's time. In international waters, time zone boundaries are meridians 15° apart, except that -<abbr>UTC</abbr>−12 and <abbr>UTC</abbr>+12 are each 7.5° +<abbr>UT</abbr>−12 and <abbr>UT</abbr>+12 are each 7.5° wide and are separated by the 180° meridian (not by the International Date Line, which is for land and territorial waters only). A captain can change ship's @@ -884,10 +884,10 @@ protocols.</li> Formats on the Web</a> surveys web- and Internet-oriented date and time formats.</li> <li>Alphabetic time zone abbreviations should not be used as unique -identifiers for <abbr>UTC</abbr> offsets as they are ambiguous in +identifiers for <abbr>UT</abbr> offsets as they are ambiguous in practice. For example, in English-speaking North America -"<abbr>CST</abbr>" denotes 6 hours behind <abbr>UTC</abbr>, -but in China it denotes 8 hours ahead of <abbr>UTC</abbr>, +"<abbr>CST</abbr>" denotes 6 hours behind <abbr>UT</abbr>, +but in China it denotes 8 hours ahead of <abbr>UT</abbr>, and French-speaking North Americans prefer "<abbr title="Heure Normale du Centre">HNC</abbr>" to "<abbr>CST</abbr>". The <code><abbr>tz</abbr></code> @@ -895,7 +895,7 @@ database contains English abbreviations for many time stamps; unfortunately some of these abbreviations were merely the database maintainers' inventions, and are gradually being removed.</li> <li>Numeric time zone abbreviations typically count hours east of -<abbr>UTC</abbr>, e.g., +09 for Japan and +<abbr>UT</abbr>, e.g., +09 for Japan and −10 for Hawaii. However, the <abbr>POSIX</abbr> <code><abbr>TZ</abbr></code> environment variable uses the opposite convention. For example, one might use <code><abbr>TZ</abbr>="<abbr @@ -909,7 +909,7 @@ confusion, handle old time stamps better, and insulate you better from any future changes to the rules. One should never set <abbr>POSIX</abbr> <code><abbr>TZ</abbr></code> to a value like <code>"GMT-9"</code>, though, since this would incorrectly imply that -local time is nine hours ahead of <abbr>UTC</abbr> and the time zone +local time is nine hours ahead of <abbr>UT</abbr> and the time zone is called "<abbr>GMT</abbr>".</li> </ul> <h2 id="see-also">See also</h2> diff --git a/tzselect.ksh b/tzselect.ksh index 759ba5f..d71a95e 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -342,8 +342,9 @@ while while echo >&2 'Please enter the desired value' \ 'of the TZ environment variable.' - echo >&2 'For example, GST-10 is a zone named GST' \ - 'that is 10 hours ahead (east) of UTC.' + echo >&2 'For example, AEST-10 is a zone named AEST' \ + 'that is 10 hours ahead (east) of UT' + echo >&2 'and does not observe daylight saving time.' read TZ $AWK -v TZ="$TZ" 'BEGIN { tzname = "(<[[:alnum:]+-]{3,}>|[[:alpha:]]{3,})" diff --git a/zdump.c b/zdump.c index d4e6084..3cd4f42 100644 --- a/zdump.c +++ b/zdump.c @@ -265,7 +265,7 @@ tzfree(timezone_t env) } #endif /* ! USE_LOCALTIME_RZ */ -/* A UTC time zone, and its initializer. */ +/* A UT time zone, and its initializer. */ static timezone_t gmtz; static void gmtzinit(void) @@ -280,7 +280,7 @@ gmtzinit(void) } } -/* Convert *TP to UTC, storing the broken-down time into *TMP. +/* Convert *TP to UT, storing the broken-down time into *TMP. Return TMP if successful, NULL otherwise. This is like gmtime_r(TP, TMP), except typically faster if USE_LOCALTIME_RZ. */ static struct tm * @@ -730,8 +730,8 @@ adjusted_yday(struct tm const *a, struct tm const *b) } #endif -/* If A is the broken-down local time and B the broken-down UTC for - the same instant, return A's UTC offset in seconds, where positive +/* If A is the broken-down local time and B the broken-down UT for + the same instant, return A's UT offset in seconds, where positive offsets are east of Greenwich. On failure, return LONG_MIN. If T is nonnull, *T is the timestamp that corresponds to A; call @@ -847,10 +847,10 @@ format_local_time(char *buf, size_t size, struct tm const *tm) : my_snprintf(buf, size, "%02d", hh)); } -/* Store into BUF, of size SIZE, a formatted UTC offset for the +/* Store into BUF, of size SIZE, a formatted UT offset for the localtime *TM corresponding to time T. Use ISO 8601 format +HHMMSS, or -HHMMSS for timestamps west of Greenwich; use the - format -00 for unknown UTC offsets. If the hour needs more than + format -00 for unknown UT offsets. If the hour needs more than two digits to represent, extend the length of HH as needed. Otherwise, omit SS if SS is zero, and omit MM too if MM is also zero. @@ -925,7 +925,7 @@ format_quoted_string(char *buf, size_t size, char const *p) %f zone name %L local time as per format_local_time - %Q like "U\t%Z\tD" where U is the UTC offset as for format_utc_offset + %Q like "U\t%Z\tD" where U is the UT offset as for format_utc_offset and D is the isdst flag; except omit D if it is zero, omit %Z if it equals U, quote and escape %Z if it contains nonalphabetics, and omit any trailing tabs. */ diff --git a/zic.8 b/zic.8 index ab95b08..43ef2ce 100644 --- a/zic.8 +++ b/zic.8 @@ -366,7 +366,7 @@ is used to show where the of the time zone abbreviation goes. Alternately, a format can use the pair of characters .B %z -to stand for the UTC offset in the form +to stand for the UT offset in the form .RI \(+- hh , .RI \(+- hhmm , or @@ -376,7 +376,7 @@ using the shortest form that does not lose information, where .IR mm , and .I ss -are the hours, minutes, and seconds east (+) or west (\(mi) of UTC. +are the hours, minutes, and seconds east (+) or west (\(mi) of UT. Alternately, a slash (/) separates standard and daylight abbreviations. diff --git a/zic.c b/zic.c index a3d7383..82e653d 100644 --- a/zic.c +++ b/zic.c @@ -2055,7 +2055,7 @@ abbroffset(char *buf, zic_t offset) minutes = offset % MINSPERHOUR; offset /= MINSPERHOUR; if (100 <= offset) { - error(_("%%z UTC offset magnitude exceeds 99:59:59")); + error(_("%%z UT offset magnitude exceeds 99:59:59")); return "%z"; } else { char *p = buf; -- 2.7.4

7 11

I'm sure everyone has seen this... but...
by merlyn＠stonehenge.com Nov. 8, 2017

Nov. 8, 2017

https://www.youtube.com/watch?v=-5wpm-gesOY -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/Dart consulting, Technical writing, Comedy, etc. etc. Still trying to think of something clever for the fourth line of this .sig

2 1

Apple watch crashes if daylight time ends
by Steve Allen Nov. 6, 2017

Nov. 6, 2017

https://www.reddit.com/r/AppleWatch/comments/7aqiw1/series_3_crashes_when_a… Reports that Apple watchOS 4.1 crashes if asked about today's weather (not tomorrow's, etc.) in a zone which is about to end daylight time. -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

3 2

Massachusetts time zone report
by Steve Allen Nov. 4, 2017

Nov. 4, 2017

Massachusetts has approved a 47 page report on its time zone http://www.eileendonoghue.org/special-commission-approves-time-zone-report/ it cautiously recommends moving to permanent Atlantic standard time. -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

3 3

Article proposes end of DST, adds interesting historic reference
by Steve Jones Nov. 4, 2017

Nov. 4, 2017

Interesting/amusing article on Fox News this morning (using the wayback machine link to reduce the oppressive spam: https://web.archive.org/web/20171104061246/http://www.foxnew s.com/opinion/2017/11/04/its-time-for-daylight-saving-time- to-fall-back-forever.html The best part was a link to an old gizmodo article containing a well-researched historical reference to Ben Franklin's original proposal for a DST-like policy: https://gizmodo.com/ben-franklins-daylight-saving-time-proposal-was-writte- 1456363759 Further clicking led me to the full letter from Ben: http://www.webexhibits.org/daylightsaving/franklin3.html which I think is tz-art worthy. Steve Jones [image: Emacs!]

2 1

Re: [tz] [IANA #985615] Sudan Time Zone change
by Mohammed Elsir Osman Alebeid Nov. 3, 2017

Nov. 3, 2017

Dear Eggert, This is Mohammed Elsir from Zain, the first mobile operator in Sudan. Actually our mobile network sends the correct time zone which is GMT+2 as seen in below trace. [cid:image015.png@01D353DB.A197A6D0] The thing is that some devices such as most of feature/legacy/old phones accept the sent time zone and change time correctly. But some Android device such as Samsung, Huawei, Lenovo and part of HTC reject the provided time zone and display the time zone based on lookup table inside the handset. Below is an example from Lenovo P2. [cid:image016.png@01D353DB.A197A6D0] Some Handset manufactures such as apple sent messages over the internet asking for handset restart to get the new time zone. Below is an examples. [cid:image003.png@01D353DD.1DA00320] I do appreciate your kind support to contact Android handset manufactures such as Samsung, Huawei and Lenovo asking them about 1. Why their handsets reject the network provided time zone. 2. How can they solve this issue? Should you need further discussion I am available on Skype @ mohammed_elsir_64 or WhatsApp @ +249912311500. Just let me know the appropriate time for you to discuss further. Thanks in advance for your kind support. Best Regards, Mohammed Elsir M.Sc., PMP,ITIL-SO From: Ahmed Ali Ahmed Ali Sent: Wednesday, November 01, 2017 8:18 PM To: Ahmed Ibrahim Ahmed Abdelkareem <Ahmed.AbdElkareem(a)sd.zain.com>; Mohammed Elsir Osman Alebeid <Mohammed.ElsirOsman(a)sd.zain.com>; Mugahed Bakri Mohammed Alhag <Mugahed.Bakri(a)sd.zain.com> Cc: Faisal El Muftah <Faisal.Nourelhuda(a)sd.zain.com>; Nizar Musa <Nizar.Musa(a)sd.zain.com>; Ali Boosh <Ali.Boosh(a)sd.zain.com>; Badr Eldin Abdalla Mohamed Nour <Badr.Nour(a)sd.zain.com> Subject: Fwd: [tz] [IANA #985615] Sudan Time Zone change Dears, Please check the below feedback from IANA Thanks, Sent from Samsung Mobile -------- Original message -------- From: ahmed.atyya(a)ntc.gov.sd<mailto:ahmed.atyya@ntc.gov.sd> Date:11/01/2017 20:19 (GMT+03:00) To: Faisal El Muftah , Ahmed Ali Ahmed Ali , Regulatory , Hiba Abbas Yousif Eltigani , Mohamed Gaafar Ibrahim Bashir Corporate Services - MTN - Sudan , Nafisa Mahmoud Karamalla Corporate Services - MTN - Sudan , Mohammed Abdelraheem Abdelmagid Elkhalifa , Munir Taha Elkabashi Hassan Elfaki Cc: abdelhafiz , Afaf Nijomi , yahia , mohamed elhaj Subject: Fwd: [tz] [IANA #985615] Sudan Time Zone change Dears Please find below email from IANA for your kind revision to find the way out; we will also discuss the proposal of Sudan Embassy regards Ahmed Atyya ----- Forwarded Message ----- From: "Paul Eggert" <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>> To: "ahmed atyya" <ahmed.atyya(a)ntc.gov.sd<mailto:ahmed.atyya@ntc.gov.sd>> Cc: "yahia" <yahia(a)ntc.gov.sd<mailto:yahia@ntc.gov.sd>>, "Matt Johnson" <mj1856(a)hotmail.com<mailto:mj1856@hotmail.com>>, "Time Zone Mailing List" <tz(a)iana.org<mailto:tz@iana.org>>, "itisalat" <itisalat(a)ntc.gov.sd<mailto:itisalat@ntc.gov.sd>>, "abdin" <abdin(a)ntc.gov.sd<mailto:abdin@ntc.gov.sd>>, "nadir" <nadir(a)ntc.gov.sd<mailto:nadir@ntc.gov.sd>>, "abdelhafiz" <abdelhafiz(a)ntc.gov.sd<mailto:abdelhafiz@ntc.gov.sd>> Sent: Wednesday, November 1, 2017 7:57:00 PM Subject: Re: [tz] [IANA #985615] Sudan Time Zone change On 11/01/2017 01:35 AM, ahmed.atyya(a)ntc.gov.sd<mailto:ahmed.atyya@ntc.gov.sd> wrote: > With respect to the topic, please be updated that the change was applied successfully, Apple > handsets did the update automatically but Android handsets didn’t. In what sense didn't they change? My Android phone's time zone menu has entries for Cairo, Harare, and Nairobi, but not for Khartoum. If it is a matter of the user's time zone settings, users need to change from (say) Nairobi time to Cairo time. On the other hand, if it is a matter of the time zone supplied from the cellular service company, then this is something for your local cell company to address. > We kindly request to communicate with Google in order to update Android OS with the changes > for the handsets take the time automatically. As I understand it, Google engineers monitor this mailing list and so already know about the time zone change. There is a gap between the time that Google releases software updates, and the time that phones actually change. For example, even though I have a Google Nexus 6P phone and live in the United States, my phone is well behind Google's release schedule: it upgraded over-the-air to Android 8.0 Oreo only last night, even though Oreo was released on August 21 *. Other manufacturers' Android phones are even slower to update. This underscores the importance of governments announcing time zone changes well in advance: we currently recommend one years' advance notice. When other countries have run into similar problems, they've had some luck by contacting the U.S. State Department and asking for its help in adjusting the priorities of commercial providers. I suggest that you contact the U.S. Deputy Chief of Mission in Sudan and ask for his advice for how to proceed. See: https://sd.usembassy.gov/our-relationship/dcm/ https://sd.usembassy.gov/embassy/khartoum/offices-departments/public-affair… From what you tell me, though, the problem is likely to involve the protocols used by your local cellular service providers (that is, the problem may not be in Android at all), so they'll need to be in contact with their suppliers too. [cid:image001.png@01D353B6.A6960840] Ahmed Ahmedali Market Power & Competition Advance Specialist Zain SD Al Mogran, Zain Building Al Ghaba Street P.O Box: 13588 Khartoum Sudan Mobile : +249912398071 Email : Ahmed.Ahmedali(a)sd.zain.com<mailto:Ahmed.Ahmedali@sd.zain.com> Web : www.zain.com<http://www.zain.com> [cid:image005.jpg@01D353DD.1DA00320]<https://twitter.com/ZainSudan> [cid:image007.jpg@01D353DD.1DA00320] <https://facebook.com/ZainSudan/?fref=ts> [cid:image009.jpg@01D353DD.1DA00320] <https://plus.google.com/110542740934974723351> [cid:image011.jpg@01D353DD.1DA00320] <https://instagram.com/zainsudan/> [cid:image013.jpg@01D353DD.1DA00320] <https://linkedin.com/company/3224878?trk=tyah&trkInfo=clickedVertical%3Acom…> [cid:image023.png@01D353DD.1DA00320] <https://youtube.com/user/ZainSudanTV> [cid:image014.png@01D353B6.A6960840] [cid:image2acf2f.BMP@a4b5ec2d.4c95cc79] Mohammed Elsir Osman CT Infrastructure Operation Team Leader Zain SD Al Mogran, Zain Building Al Ghaba Street P.O Box: 13588 Khartoum Sudan Mobile : ++249912311500 Office : +24990001-3256 Email : Mohammed.ElsirOsman(a)sd.zain.com Web : www.zain.com [cid:image1d8d7d.PNG@e9fa88a4.43aeded8]<https://twitter.com/ZainSudan> [cid:imaged5af34.PNG@146f7ddf.4e95af19] <https://facebook.com/ZainSudan/?fref=ts> [cid:image95f784.PNG@eb17dd26.4eb485d3] <https://plus.google.com/110542740934974723351> [cid:imageb1c854.JPG@2f1af4fa.4680f52e] <https://instagram.com/zainsudan/> [cid:imagead7fe1.PNG@0e87976d.42b9ff22] <https://linkedin.com/company/3224878?trk=tyah&trkInfo=clickedVertical%3Acom…> [cid:image108d42.PNG@d8c0b630.439783e1] <https://youtube.com/user/ZainSudanTV> [cid:image400fba.PNG@9f5f39e1.45ab1906]

4 3

Regarding changes of time format the Philippines
by Arati Nov. 3, 2017

Nov. 3, 2017

Hi , We are using tzdb for all our customers. With latest update of tzdb to 2017a, one of the customer came back with issue in time format display in logs. The timezone for this Customer is Asia/Manila i.e. Philippines. Before use on 2017a tzdb , the time displayed is as follows 2017-10-31 16:47:33.930 +0800 After using 2017a tzdb time displayed as 2017-10-31 08:48:38.056 +0000 We observed the same issue using perl DateTime module too. We could see that the time format for this zone is changed from PH%sT to +08/+09. This change is there only in asia file.(Note reverting back this change and recompiling tzdb resolves the issue) We are looking for a solution for this. We are not clear whether some dependent library needs to be upgraded , or it is a bug in tzdb. Kindly address the query and help to resolve the issue. Thanks & Regards, Arati =========================================================== Learn how to protect users, data, and applications with security engineered for the public cloud by Barracuda. http://barracuda.com DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. ===========================================================

4 7

Re: [tz] [IANA #985615] Sudan Time Zone change
by Zhouyuxiang Nov. 3, 2017

Nov. 3, 2017

Dears, I'm not that sure. But I guess this is same problem as mine([time zone problem about 2017c] (Zefram)). This just happen in Android system now. Because the tzcode2017c.tar.gz has one error. external\icu\tools\update-tzdata.py Android use this script to update the tz data from IANA via internet. But africa file and backzone file have a duplicated data that made the update script error: # South Sudan Zone Africa/Juba 2:06:24 - LMT 1931 2:00 Sudan CA%sT 2000 Jan 15 12:00 3:00 - EAT So android device could not update the time zone data normally. I deleted one in backzone, then it worked in local. And Zefram told me "No one noticed in advance of release because few people use 'backzone'". So I infer that the old phone and ios system will not use backzone data, so they could update normally. I think you have two way to solve this problem. 1.Wait IANA modify the "backzone" data, so the internet updating could work. 2.Let Android device Manufacturers do this update themselves: a. Delete the duplicated data as I did. b. Modify the update-tzdata.py to update time zone data without internet. ---------------------------------------------------------------------- Message: 1 Date: Thu, 2 Nov 2017 11:19:09 +0000 From: Mohammed Elsir Osman Alebeid <Mohammed.ElsirOsman(a)sd.zain.com> To: "eggert(a)cs.ucla.edu" <eggert(a)cs.ucla.edu> Cc: Ali Boosh <Ali.Boosh(a)sd.zain.com>, "itisalat(a)ntc.gov.sd" <itisalat(a)ntc.gov.sd>, "abdin(a)ntc.gov.sd" <abdin(a)ntc.gov.sd>, "nadir(a)ntc.gov.sd" <nadir(a)ntc.gov.sd>, "tz(a)iana.org" <tz(a)iana.org>, Nizar Musa <Nizar.Musa(a)sd.zain.com>, "abdelhafiz(a)ntc.gov.sd" <abdelhafiz(a)ntc.gov.sd>, Ahmed Ali Ahmed Ali <Ahmed.Ahmedali(a)sd.zain.com>, "yahia(a)ntc.gov.sd" <yahia(a)ntc.gov.sd>, Mugahed Bakri Mohammed Alhag <Mugahed.Bakri(a)sd.zain.com>, Ahmed Ibrahim Ahmed Abdelkareem <Ahmed.AbdElkareem(a)sd.zain.com>, Badr Eldin Abdalla Mohamed Nour <Badr.Nour(a)sd.zain.com>, Faisal El Muftah <Faisal.Nourelhuda(a)sd.zain.com> Subject: Re: [tz] [IANA #985615] Sudan Time Zone change Message-ID: <BE1CCE5C566B134083665B1FF5684AE58BCDD6E4(a)sr-ark-mbxb.sd.zain.com> Content-Type: text/plain; charset="utf-8" Dear Eggert, This is Mohammed Elsir from Zain, the first mobile operator in Sudan. Actually our mobile network sends the correct time zone which is GMT+2 as seen in below trace. [cid:image015.png@01D353DB.A197A6D0] The thing is that some devices such as most of feature/legacy/old phones accept the sent time zone and change time correctly. But some Android device such as Samsung, Huawei, Lenovo and part of HTC reject the provided time zone and display the time zone based on lookup table inside the handset. Below is an example from Lenovo P2. [cid:image016.png@01D353DB.A197A6D0] Some Handset manufactures such as apple sent messages over the internet asking for handset restart to get the new time zone. Below is an examples. [cid:image003.png@01D353DD.1DA00320] I do appreciate your kind support to contact Android handset manufactures such as Samsung, Huawei and Lenovo asking them about 1. Why their handsets reject the network provided time zone. 2. How can they solve this issue? Should you need further discussion I am available on Skype @ mohammed_elsir_64 or WhatsApp @ +249912311500. Just let me know the appropriate time for you to discuss further. Thanks in advance for your kind support. Best Regards, Mohammed Elsir M.Sc., PMP,ITIL-SO From: Ahmed Ali Ahmed Ali Sent: Wednesday, November 01, 2017 8:18 PM To: Ahmed Ibrahim Ahmed Abdelkareem <Ahmed.AbdElkareem(a)sd.zain.com>; Mohammed Elsir Osman Alebeid <Mohammed.ElsirOsman(a)sd.zain.com>; Mugahed Bakri Mohammed Alhag <Mugahed.Bakri(a)sd.zain.com> Cc: Faisal El Muftah <Faisal.Nourelhuda(a)sd.zain.com>; Nizar Musa <Nizar.Musa(a)sd.zain.com>; Ali Boosh <Ali.Boosh(a)sd.zain.com>; Badr Eldin Abdalla Mohamed Nour <Badr.Nour(a)sd.zain.com> Subject: Fwd: [tz] [IANA #985615] Sudan Time Zone change Dears, Please check the below feedback from IANA Thanks, Sent from Samsung Mobile -------- Original message -------- From: ahmed.atyya(a)ntc.gov.sd<mailto:ahmed.atyya@ntc.gov.sd> Date:11/01/2017 20:19 (GMT+03:00) To: Faisal El Muftah , Ahmed Ali Ahmed Ali , Regulatory , Hiba Abbas Yousif Eltigani , Mohamed Gaafar Ibrahim Bashir Corporate Services - MTN - Sudan , Nafisa Mahmoud Karamalla Corporate Services - MTN - Sudan , Mohammed Abdelraheem Abdelmagid Elkhalifa , Munir Taha Elkabashi Hassan Elfaki Cc: abdelhafiz , Afaf Nijomi , yahia , mohamed elhaj Subject: Fwd: [tz] [IANA #985615] Sudan Time Zone change Dears Please find below email from IANA for your kind revision to find the way out; we will also discuss the proposal of Sudan Embassy regards Ahmed Atyya ----- Forwarded Message ----- From: "Paul Eggert" <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>> To: "ahmed atyya" <ahmed.atyya(a)ntc.gov.sd<mailto:ahmed.atyya@ntc.gov.sd>> Cc: "yahia" <yahia(a)ntc.gov.sd<mailto:yahia@ntc.gov.sd>>, "Matt Johnson" <mj1856(a)hotmail.com<mailto:mj1856@hotmail.com>>, "Time Zone Mailing List" <tz(a)iana.org<mailto:tz@iana.org>>, "itisalat" <itisalat(a)ntc.gov.sd<mailto:itisalat@ntc.gov.sd>>, "abdin" <abdin(a)ntc.gov.sd<mailto:abdin@ntc.gov.sd>>, "nadir" <nadir(a)ntc.gov.sd<mailto:nadir@ntc.gov.sd>>, "abdelhafiz" <abdelhafiz(a)ntc.gov.sd<mailto:abdelhafiz@ntc.gov.sd>> Sent: Wednesday, November 1, 2017 7:57:00 PM Subject: Re: [tz] [IANA #985615] Sudan Time Zone change On 11/01/2017 01:35 AM, ahmed.atyya(a)ntc.gov.sd<mailto:ahmed.atyya@ntc.gov.sd> wrote: > With respect to the topic, please be updated that the change was > applied successfully, Apple handsets did the update automatically but Android handsets didn?t. In what sense didn't they change? My Android phone's time zone menu has entries for Cairo, Harare, and Nairobi, but not for Khartoum. If it is a matter of the user's time zone settings, users need to change from (say) Nairobi time to Cairo time. On the other hand, if it is a matter of the time zone supplied from the cellular service company, then this is something for your local cell company to address. > We kindly request to communicate with Google in order to update > Android OS with the changes for the handsets take the time automatically. As I understand it, Google engineers monitor this mailing list and so already know about the time zone change. There is a gap between the time that Google releases software updates, and the time that phones actually change. For example, even though I have a Google Nexus 6P phone and live in the United States, my phone is well behind Google's release schedule: it upgraded over-the-air to Android 8.0 Oreo only last night, even though Oreo was released on August 21 *. Other manufacturers' Android phones are even slower to update. This underscores the importance of governments announcing time zone changes well in advance: we currently recommend one years' advance notice. When other countries have run into similar problems, they've had some luck by contacting the U.S. State Department and asking for its help in adjusting the priorities of commercial providers. I suggest that you contact the U.S. Deputy Chief of Mission in Sudan and ask for his advice for how to proceed. See: https://sd.usembassy.gov/our-relationship/dcm/ https://sd.usembassy.gov/embassy/khartoum/offices-departments/public-affair… From what you tell me, though, the problem is likely to involve the protocols used by your local cellular service providers (that is, the problem may not be in Android at all), so they'll need to be in contact with their suppliers too. [cid:image001.png@01D353B6.A6960840] Ahmed Ahmedali Market Power & Competition Advance Specialist Zain SD Al Mogran, Zain Building Al Ghaba Street P.O Box: 13588 Khartoum Sudan Mobile : +249912398071 Email : Ahmed.Ahmedali(a)sd.zain.com<mailto:Ahmed.Ahmedali@sd.zain.com> Web : www.zain.com<http://www.zain.com> [cid:image005.jpg@01D353DD.1DA00320]<https://twitter.com/ZainSudan> [cid:image007.jpg@01D353DD.1DA00320] <https://facebook.com/ZainSudan/?fref=ts> [cid:image009.jpg@01D353DD.1DA00320] <https://plus.google.com/110542740934974723351> [cid:image011.jpg@01D353DD.1DA00320] <https://instagram.com/zainsudan/> [cid:image013.jpg@01D353DD.1DA00320] <https://linkedin.com/company/3224878?trk=tyah&trkInfo=clickedVertical%3Acom…> [cid:image023.png@01D353DD.1DA00320] <https://youtube.com/user/ZainSudanTV> [cid:image014.png@01D353B6.A6960840] [cid:image2acf2f.BMP@a4b5ec2d.4c95cc79] Mohammed Elsir Osman CT Infrastructure Operation Team Leader Zain SD Al Mogran, Zain Building Al Ghaba Street P.O Box: 13588 Khartoum Sudan Mobile : ++249912311500 Office : +24990001-3256 Email : Mohammed.ElsirOsman(a)sd.zain.com Web : www.zain.com [cid:image1d8d7d.PNG@e9fa88a4.43aeded8]<https://twitter.com/ZainSudan> [cid:imaged5af34.PNG@146f7ddf.4e95af19] <https://facebook.com/ZainSudan/?fref=ts> [cid:image95f784.PNG@eb17dd26.4eb485d3] <https://plus.google.com/110542740934974723351> [cid:imageb1c854.JPG@2f1af4fa.4680f52e] <https://instagram.com/zainsudan/> [cid:imagead7fe1.PNG@0e87976d.42b9ff22] <https://linkedin.com/company/3224878?trk=tyah&trkInfo=clickedVertical%3Acom…> [cid:image108d42.PNG@d8c0b630.439783e1] <https://youtube.com/user/ZainSudanTV> [cid:image400fba.PNG@9f5f39e1.45ab1906]

1 0

Ulaanbaatar Time Zone Correction
by Brian M. Vibert Nov. 2, 2017

Nov. 2, 2017

Hello, Looking into the asia file, I see a listing comment for # From Ganbold Tsagaankhuu (2017-02-09): # Mongolian Government meeting has concluded today to cancel daylight # saving time adoption in Mongolia. Source: http://zasag.mn/news/view/16192 Which is correct, however, it appears that the change has not been propagated to the Zone as seen here # Ulaanbaatar, a.k.a. Ulan Bataar, Ulan Bator, Urga Zone Asia/Ulaanbaatar 7:07:32 - LMT 1905 Aug 7:00 - +07 1978 8:00 Mongol +08/+09 It should just be 8:00 across the board at all times. -- *Brian M. Vibert | L3 Technical Support Engineer* *e: **bvibert(a)instructure.com <bvibert(a)instructure.com>* *c: 801.913.4236| **instructure.com* <http://www.instructure.com/> <https://www.instructure.com/>

2 1