From arthurdavidolson at gmail.com  Sun Dec  1 19:34:26 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Sun, 1 Dec 2019 14:34:26 -0500
Subject: [tz] Addition to tz-art.html
Message-ID: <CAJvZEYmo4XhSPwa6cMvkijPYpTFKU0KEj0e-ReQFzV1ZVECqAw@mail.gmail.com>

This lament about the difficulty of time calculation peaked at number 7 on
the U. S. Billboard chart.

    @dashdashado

*** old/tz-art.html Sun Dec  1 14:12:32 2019
--- new/tz-art.html Sun Dec  1 14:28:34 2019
***************
*** 458,463 ****
--- 458,472 ----
  <tr><td><a href="
https://www.allmusic.com/album/youre-getting-better-the-word-jazz-dot-masters-mw0000736197">AMG
Rating</a></td><td>4.5 stars</td></tr>
  <tr><td>Notes</td><td>Includes the piece "What Time Is It"
  ("He knew what time it was everywhere...that counted").</td></tr>
+ <tr><td>&nbsp;</td><td></td></tr>
+ <tr><td>Artist</td><td>Chicago</td></tr>
+ <tr><td>CD</td><td>Chicago Transit Authority</td></tr>
+ <tr><td>Copyright Date</td><td>1969</td></tr>
+ <tr><td>Label</td><td>Columbia</td></tr>
+ <tr><td>ID</td><td>64409</td></tr>
+ <tr><td>Total Time</td><td>1:16:20</td></tr>
+ <tr><td><a href="
https://www.allmusic.com/album/chicago-transit-authority-mw0000189364">AMG
Rating</a></td><td>4 stars</td></tr>
+ <tr><td>Notes</td><td>Includes the song "Does Anybody Really Know What
Time It Is?"</td></tr>
  </table>
  <h2>Comics</h2>
  <ul>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191201/28f44985/attachment.html>
-------------- next part --------------
*** old/tz-art.html	Sun Dec  1 14:12:32 2019
--- new/tz-art.html	Sun Dec  1 14:28:34 2019
***************
*** 458,463 ****
--- 458,472 ----
  <tr><td><a href="https://www.allmusic.com/album/youre-getting-better-the-word-jazz-dot-masters-mw0000736197">AMG Rating</a></td><td>4.5 stars</td></tr>
  <tr><td>Notes</td><td>Includes the piece "What Time Is It"
  ("He knew what time it was everywhere...that counted").</td></tr>
+ <tr><td>&nbsp;</td><td></td></tr>
+ <tr><td>Artist</td><td>Chicago</td></tr>
+ <tr><td>CD</td><td>Chicago Transit Authority</td></tr>
+ <tr><td>Copyright Date</td><td>1969</td></tr>
+ <tr><td>Label</td><td>Columbia</td></tr>
+ <tr><td>ID</td><td>64409</td></tr>
+ <tr><td>Total Time</td><td>1:16:20</td></tr>
+ <tr><td><a href="https://www.allmusic.com/album/chicago-transit-authority-mw0000189364">AMG Rating</a></td><td>4 stars</td></tr>
+ <tr><td>Notes</td><td>Includes the song "Does Anybody Really Know What Time It Is?"</td></tr>
  </table>
  <h2>Comics</h2>
  <ul>

From arthurdavidolson at gmail.com  Sun Dec  1 19:53:04 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Sun, 1 Dec 2019 14:53:04 -0500
Subject: [tz] tz-art.html playlist
Message-ID: <CAJvZEYm8Tka+VJUo-v3NdumxbHZiZZiYBaRhziLVgBe06Uhgmw@mail.gmail.com>

A playlist of 22 of the tunes noted in tz-art.html is now available at...
    https://open.spotify.com/playlist/681bJSY7FY7ppzLOcmYPdh

Nerdiest. Party. Ever.

    @dashdashado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191201/81ce0799/attachment.html>

From skeet at pobox.com  Mon Dec  2 17:48:35 2019
From: skeet at pobox.com (Jon Skeet)
Date: Mon, 2 Dec 2019 17:48:35 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>

Could you clarify *exactly *how you derived your table, in terms of the
IANA data?

If you look at
https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul -
which is generated from IANA data - it shows DST changes stopping in
September 2016, just as you said.

Likewise if you look at the current source data
<https://github.com/eggert/tz/blob/1a27ec76bc436a64070461bbbf28e0511c7cf3b8/europe#L3889>,
you'll see the same result.

I suspect this is a problem of data interpretation rather than anything
else.

Jon


On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com>
wrote:

> Hello,
>
>
>
> I?d like to report your downloads for the following Time Zones from this
> URL on your site are out of date: https://www.iana.org/time-zones
>
>
>
> For instance Europe/Istanbul moved to UTC 3 permanently in September of
> 2016 and no longer follow DST.
>
>
>
> I will place the correct times first, and then the incorrect IANA times
> second. Highlighted in orange have the incorrect time zone information (0
> means there is no DST, 1 means they follow DST)
>
>
>
>
>
> TimeZone
>
> UTC Offset
>
> ObservesDST
>
> IANA_UTC_offset:
>
> IANA_ObservesDST:
>
> America/Campo_Grande
>
> -4
>
> 0
>
> -4
>
> 1
>
> America/Sao_Paulo
>
> -3
>
> 0
>
> -3
>
> 1
>
> America/St_Johns
>
> -3.5
>
> 1
>
> -3
>
> 1
>
> Asia/Sakhalin
>
> 11
>
> 0
>
> 10
>
> 0
>
> Australia/Adelaide
>
> 9.5
>
> 1
>
> 9
>
> 1
>
> Australia/Darwin
>
> 9.5
>
> 0
>
> 9
>
> 0
>
> Australia/Lord_Howe
>
> 10.5
>
> 1
>
> 10
>
> 1
>
> Europe/Istanbul
>
> 3
>
> 0
>
> 2
>
> 1
>
> Indian/Cocos
>
> 6.5
>
> 0
>
> 6
>
> 0
>
> Pacific/Chatham
>
> 12.75
>
> 1
>
> 12
>
> 1
>
>
>
> Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191202/e730a096/attachment.html>

From Paul.Koning at dell.com  Mon Dec  2 17:52:28 2019
From: Paul.Koning at dell.com (Paul.Koning at dell.com)
Date: Mon, 2 Dec 2019 17:52:28 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <595268F5-0D29-484E-8279-1EE35BCF4A57@dell.com>

You may have broken tools.

The data looks correct to me.  For example, the Australia ones clearly have x:30 (half hour) offsets.  If you're not getting that, your parser and/or time formatting code may be defective.

paul


On Nov 25, 2019, at 8:04 PM, Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:


[EXTERNAL EMAIL]

Hello,

I?d like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones

For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST.

I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST)


TimeZone

UTC Offset

ObservesDST

IANA_UTC_offset:

IANA_ObservesDST:

America/Campo_Grande

-4

0

-4

1

America/Sao_Paulo

-3

0

-3

1

America/St_Johns

-3.5

1

-3

1

Asia/Sakhalin

11

0

10

0

Australia/Adelaide

9.5

1

9

1

Australia/Darwin

9.5

0

9

0

Australia/Lord_Howe

10.5

1

10

1

Europe/Istanbul

3

0

2

1

Indian/Cocos

6.5

0

6

0

Pacific/Chatham

12.75

1

12

1


Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191202/c7b9ed9d/attachment-0001.html>

From Benjamin.Weiser at inrix.com  Mon Dec  2 18:59:09 2019
From: Benjamin.Weiser at inrix.com (Benjamin Weiser)
Date: Mon, 2 Dec 2019 18:59:09 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
Message-ID: <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>

Thank you Jon,

I will have the dev take a look at why his tools are not refreshing the data correctly.  I do see the correct values in the links that you provided and in the download I mentioned. We were in the process of consolidating two teams that were sourcing TimeZones from different data sources. The team using IANA was claiming they were refreshing, so something must be going wrong with their tools as you suggested.

I appreciate the feedback.

From: Jon Skeet <skeet at pobox.com>
Sent: Monday, December 2, 2019 9:49 AM
To: Benjamin Weiser <Benjamin.Weiser at inrix.com>
Cc: tz at iana.org
Subject: Re: [tz] incorrect timezone info from tar files

Could you clarify exactly how you derived your table, in terms of the IANA data?

If you look at https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnodatime.org%2Ftzvalidate%2Fgenerate%3Fversion%3D2019c%26zone%3DEurope%2FIstanbul&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446283964&sdata=Z0%2Bx2yU00vEkAzTGo5Ur7NHttfjLRqsgX2y4E7j0dMg%3D&reserved=0> - which is generated from IANA data - it shows DST changes stopping in September 2016, just as you said.

Likewise if you look at the current source data<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feggert%2Ftz%2Fblob%2F1a27ec76bc436a64070461bbbf28e0511c7cf3b8%2Feurope%23L3889&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446288944&sdata=%2Bs4k7r5pNGwBw0lhOUEIcDYUrxWsKxdR2j5H7VWkXnI%3D&reserved=0>, you'll see the same result.

I suspect this is a problem of data interpretation rather than anything else.

Jon


On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:
Hello,

I?d like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Ftime-zones&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446293919&sdata=E4593Nqq4EaQadhjoAmDv7Ww9oy%2F2YcO7ByNps5SYA4%3D&reserved=0>

For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST.

I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST)


TimeZone
UTC Offset
ObservesDST
IANA_UTC_offset:
IANA_ObservesDST:
America/Campo_Grande
-4
0
-4
1
America/Sao_Paulo
-3
0
-3
1
America/St_Johns
-3.5
1
-3
1
Asia/Sakhalin
11
0
10
0
Australia/Adelaide
9.5
1
9
1
Australia/Darwin
9.5
0
9
0
Australia/Lord_Howe
10.5
1
10
1
Europe/Istanbul
3
0
2
1
Indian/Cocos
6.5
0
6
0
Pacific/Chatham
12.75
1
12
1

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191202/d5b40d16/attachment-0001.html>

From eggert at cs.ucla.edu  Mon Dec  2 19:31:45 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Mon, 2 Dec 2019 11:31:45 -0800
Subject: [tz] Unnecessary time zones in Ukraine territory
In-Reply-To: <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
Message-ID: <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>

On 11/26/19 6:04 AM, Mikhail Gribanov wrote:

>> Europe/Uzhgorod
>> Europe/Zaporozhye
>>
>> Can you explain why they were added? I did not find any evidence of
>> the existence of events "Ruthenia used CET 1990/1991" (comment in tz
>> database).

As I recall, they were added because Shanks's International Atlas had 
them. The "europe" file says:

# Unless otherwise specified, the source for data through 1990 is:
# Thomas G. Shanks and Rique Pottenger, The International Atlas (6th 
edition),
# San Diego: ACS Publications, Inc. (2003).
# Unfortunately this book contains many errors and cites no sources.

It's quite possible that Shanks was wrong, or that I transcribed Shanks 
incorrectly. If so, it'd be helpful to provide evidence of the error, so 
that we can fix tzdb.

From eggert at cs.ucla.edu  Mon Dec  2 19:41:38 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Mon, 2 Dec 2019 11:41:38 -0800
Subject: [tz] Help on Updating Java Time ZOne
In-Reply-To: <VI1PR06MB4029D9840DF78457854495E49D470@VI1PR06MB4029.eurprd06.prod.outlook.com>
References: <VI1PR06MB4029D9840DF78457854495E49D470@VI1PR06MB4029.eurprd06.prod.outlook.com>
Message-ID: <84250fe1-e420-80a8-e655-69486e324a3f@cs.ucla.edu>

On 11/28/19 11:26 AM, Santos, Cosme wrote:

>  ??????????????? What is tzcode and tzdb, should I update them to?

Please see <https://data.iana.org/time-zones/tz-link.html> for more 
about tzcode and tzdb. If your application uses routines not written in 
Java, you'll also need to update your operating system's time zone 
tables; details depend on the OS.

>  ??????????????? Also, the Brazil Timezone change, 2019 we won?t have 
> it, so a friend sent me the tzdata2019c-rearguard.tar.gz (is this a good 
> file?)

That depends on your friend. You can generate your own 
tzdata2019c-rearguard.tar.gz file by following the instructions in the 
main tzdb distribution.

If your problem is purely Java-related, you might have better luck 
updating to a more-recent Java release. If you're using Oracle Java, 
<https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html> 
suggests that you run 7u241, 8u231, 11.0.50, 13.0.1, or later.

From eggert at cs.ucla.edu  Tue Dec  3 02:28:56 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Mon, 2 Dec 2019 18:28:56 -0800
Subject: [tz] USG_COMPAT and POSIX and XOPEN macros
In-Reply-To: <CAA0nTRuwpznqTJcZZ3Kfa=r-Dkh1zfdzLcga_f7gfn2PDzvuQw@mail.gmail.com>
References: <CAA0nTRtKgsvV8YDwaKNqwCjOX-teqW5aXEJZeQW-NVt7iNgA7A@mail.gmail.com>
 <27723656-ee4b-7523-12e0-55f1c484240d@cs.ucla.edu>
 <CAA0nTRvCPkPHCOH71FC_eX9rXAhb3eY+qGDynzqtW4CAhTrNLA@mail.gmail.com>
 <138de0a4-2e9a-4f96-931e-397fa54ff8b3@cs.ucla.edu>
 <CAA0nTRuwpznqTJcZZ3Kfa=r-Dkh1zfdzLcga_f7gfn2PDzvuQw@mail.gmail.com>
Message-ID: <c6c65e37-a17b-010e-49a5-65c3f1989d79@cs.ucla.edu>

On 11/30/19 7:31 AM, Andras Farkas wrote:
> On Fri, Nov 29, 2019 at 2:55 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> However, on FreeBSD (thinking back to the connections between this
> thread and another thread) compilation fails with:
> CFLAGS= -DUSG_COMPAT=2 -DHAVE_POSIX_DECLS=0
> I suggest something like the attached diff, which makes compilation
> succeed, while fitting in line with what the internal macros are
> currently doing.

Thanks for the bug report. Unfortunately that patch would refer to 
TZ_TIME_T before it's defined, and TZ_TIME_T's definition depends on 
time.h which must be included after the first part of the patch. So I 
installed the attached patch, which does not refer to TZ_TIME_H and 
which I hope fixes the problem in a simpler way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-DUSG_COMPAT-2-on-FreeBSD.patch
Type: text/x-patch
Size: 1445 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20191202/fa1cac40/0001-Support-DUSG_COMPAT-2-on-FreeBSD.patch>

From eggert at cs.ucla.edu  Tue Dec  3 02:40:08 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Mon, 2 Dec 2019 18:40:08 -0800
Subject: [tz] Addition to tz-art.html
In-Reply-To: <CAJvZEYmo4XhSPwa6cMvkijPYpTFKU0KEj0e-ReQFzV1ZVECqAw@mail.gmail.com>
References: <CAJvZEYmo4XhSPwa6cMvkijPYpTFKU0KEj0e-ReQFzV1ZVECqAw@mail.gmail.com>
Message-ID: <bfc8e462-5dd9-9fb6-69c0-fce008f792dc@cs.ucla.edu>

Thanks, I installed that.

From deepbluemistake at gmail.com  Tue Dec  3 02:57:27 2019
From: deepbluemistake at gmail.com (Andras Farkas)
Date: Mon, 2 Dec 2019 21:57:27 -0500
Subject: [tz] USG_COMPAT and POSIX and XOPEN macros
In-Reply-To: <c6c65e37-a17b-010e-49a5-65c3f1989d79@cs.ucla.edu>
References: <CAA0nTRtKgsvV8YDwaKNqwCjOX-teqW5aXEJZeQW-NVt7iNgA7A@mail.gmail.com>
 <27723656-ee4b-7523-12e0-55f1c484240d@cs.ucla.edu>
 <CAA0nTRvCPkPHCOH71FC_eX9rXAhb3eY+qGDynzqtW4CAhTrNLA@mail.gmail.com>
 <138de0a4-2e9a-4f96-931e-397fa54ff8b3@cs.ucla.edu>
 <CAA0nTRuwpznqTJcZZ3Kfa=r-Dkh1zfdzLcga_f7gfn2PDzvuQw@mail.gmail.com>
 <c6c65e37-a17b-010e-49a5-65c3f1989d79@cs.ucla.edu>
Message-ID: <CAA0nTRuywSs+BZEHQ6Bm_+Vb8Sei7furz-A60xEfcBkOVdgPhg@mail.gmail.com>

On Mon, Dec 2, 2019 at 9:28 PM Paul Eggert <eggert at cs.ucla.edu> wrote:
> Thanks for the bug report. Unfortunately that patch would refer to
> TZ_TIME_T before it's defined, and TZ_TIME_T's definition depends on
> time.h which must be included after the first part of the patch. So I
Oh!  Good point.
> installed the attached patch, which does not refer to TZ_TIME_H and
> which I hope fixes the problem in a simpler way.
This looks good and runs perfectly.
Both
CFLAGS= -DUSG_COMPAT=2
CFLAGS= -DUSG_COMPAT=2 -DHAVE_POSIX_DECLS=0
work A-OK now!
Thanks! :D

From alois at astro.ch  Tue Dec  3 11:11:53 2019
From: alois at astro.ch (Alois Treindl)
Date: Tue, 3 Dec 2019 12:11:53 +0100
Subject: [tz] Unnecessary time zones in Ukraine territory?
In-Reply-To: <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
Message-ID: <07bc0b5a-a7ef-d17f-29e9-c511004ca58f@astro.ch>

An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/ac66dc8d/attachment-0001.html>

From alois at astro.ch  Tue Dec  3 12:38:56 2019
From: alois at astro.ch (Alois Treindl)
Date: Tue, 3 Dec 2019 13:38:56 +0100
Subject: [tz] Unnecessary time zones in Ukraine territory?
In-Reply-To: <07bc0b5a-a7ef-d17f-29e9-c511004ca58f@astro.ch>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
 <07bc0b5a-a7ef-d17f-29e9-c511004ca58f@astro.ch>
Message-ID: <de90982a-5583-959b-184c-8f597bd07c81@astro.ch>

An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/d6ff4cf1/attachment.html>

From alois at astro.ch  Tue Dec  3 12:58:14 2019
From: alois at astro.ch (Alois Treindl)
Date: Tue, 3 Dec 2019 13:58:14 +0100
Subject: [tz] Unnecessary time zones in Ukraine territory?
In-Reply-To: <de90982a-5583-959b-184c-8f597bd07c81@astro.ch>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
 <07bc0b5a-a7ef-d17f-29e9-c511004ca58f@astro.ch>
 <de90982a-5583-959b-184c-8f597bd07c81@astro.ch>
Message-ID: <7840e11b-ab06-986d-85bc-dfe2005f65ff@astro.ch>

An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/96538aef/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ciekhhicmonlbejg.png
Type: image/png
Size: 138944 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/96538aef/ciekhhicmonlbejg-0001.png>

From Brian.Inglis at SystematicSw.ab.ca  Tue Dec  3 20:20:09 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Tue, 3 Dec 2019 13:20:09 -0700
Subject: [tz] Help on Updating Java Time Zone
In-Reply-To: <84250fe1-e420-80a8-e655-69486e324a3f@cs.ucla.edu>
References: <VI1PR06MB4029D9840DF78457854495E49D470@VI1PR06MB4029.eurprd06.prod.outlook.com>
 <84250fe1-e420-80a8-e655-69486e324a3f@cs.ucla.edu>
Message-ID: <879a93ff-9a38-19ce-59e3-be6d975ab6d8@SystematicSw.ab.ca>


On 2019-12-02 12:41, Paul Eggert wrote:
> On 11/28/19 11:26 AM, Santos, Cosme wrote:
>> What is tzcode and tzdb, should I update them to?
> Please see <https://data.iana.org/time-zones/tz-link.html> for more about tzcode
> and tzdb. If your application uses routines not written in Java, you'll also
> need to update your operating system's time zone tables; details depend on the OS.

...and JDKs, Java Libraries, and JVMs: GNU Classpath, Google/Android/Dalvik,
IBM/Eclipse/OpenJ9, OpenJDK, Oracle/SUN, IKVM, JAM, Jikes, Kaffe, Sable, etc.

It may perhaps be better to refer folks to their Java application, JDK, or JVM
provider for information about TZ updates.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

From Brian.Inglis at SystematicSw.ab.ca  Tue Dec  3 22:35:08 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Tue, 3 Dec 2019 15:35:08 -0700
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <e0613ed5-cbe0-489b-9b0b-16e182ca2b79@SystematicSw.ab.ca>

> On 2019-12-02 11:59, Benjamin Weiser wrote:
>> On Monday, December 2, 2019 9:49 AM, Jon Skeet wrote:
>>> On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser wrote:
>>>> I?d like to report your downloads for the following Time Zones from
>>>> this URL on your site are out of date: https://www.iana.org/time-zones>>>> For instance Europe/Istanbul moved to UTC 3 permanently in September of
>>>> 2016 and no longer follow DST.
>>>> I will place the correct times first, and then the incorrect IANA
>>>> times second. Highlighted in orange have the incorrect time zone
>>>> information (0 means there is no DST, 1 means they follow DST)

>>> Could you clarify /exactly /how you derived your table, in terms of the
>>> IANA data?
>>> If you look at 
>>> https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul
>>> - which is generated from IANA data - it shows DST changes stopping in
>>> September 2016, just as you said.
>>> Likewise if you look at the current source data, you'll see the same
>>> result.
>>> I suspect this is a problem of data interpretation rather than anything
>>> else.

>> I will have the dev take a look at why his tools are not refreshing the data
>> correctly. I do see the correct values in the links that you provided and in
>> the download I mentioned. We were in the process of consolidating two teams that
>> were sourcing TimeZones from different data sources. The team using IANA was
>> claiming they were refreshing, so something must be going wrong with their tools
>> as you suggested.

With a history of 215 code and 248 data releases over 27 years so far, with info
from hundreds of contributors across the globe every year, fed downstream to all
major systems, distros, vendors, orgs, projects, products, and languages,
feedback is similarly global, continuous, and timely; sometimes waiting weeks or
months for official government confirmation in announcements, decrees, laws,
orders, or regulations.

The list continually fields complaints that the data is out of date, when it is
the poster's systems, distros, vendors, orgs, projects, products, or languages
that are more likely to be out of date.
As this list and tzdb are one of the global sources for providing correct
localized date/time internationally, your other sources are most likely incorrect.
A simple search of the list archives would provide confirmation that the change

When applications are wrong, 90%+ of the time it is a specification or
implementation issue (and 90%+ of implementation issues are array or memory
access issues).
More likely your devs are trying to interpret the timezone data, rather than
just using it through the provided API, trying to be "efficient" or "smart",
rather than correct internationally.

The calendar, date/time, time zone/DST, locale, and internationalization APIs
are somewhat involved and unwieldy because people, languages, and countries are
inconsistent and difficult to deal with, especially if you want to do so correctly.

Treating date/time stamps and associated APIs as anything other than opaque
objects and methods leads to disaster, as we found during Y2K remediation.

In subsequent and current development, idiots still use two digit years and
non-standard opaque storage and I/O formats (anything other than mm/dd/yyyy in
US and yyyy-mm-dd everywhere; up to 2012 most others were uninterpretably
ambiguous during the first 12 days each month), pick apart dates, times,
subfields, try to convert them independently, and are surprised how often the
results are bad!

Developers should take whatever they have as a date/time stamp or string and
pass it through an opaque wrapper function, that calls all the standard API
functions in the required order, including any locale and internationalization
interpretations, to produce the complete desired result date/time stamp or
string. All other approaches are doomed to failure!

Many, often humorous, articles for developers have been written of the form: do
you know how many (one of:) seconds, minutes, hours, days, weeks, months, years,
centuries, millenia, are in (some larger measure of time), and the answers are
always as abstruse, obscure, and varied, as similar articles about how many
ounces were in bushels or barrels, when such units were in common use.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

From mikhail.gribanov at gmail.com  Tue Dec  3 09:14:39 2019
From: mikhail.gribanov at gmail.com (Mikhail Gribanov)
Date: Tue, 3 Dec 2019 11:14:39 +0200
Subject: [tz] Unnecessary time zones in Ukraine territory
In-Reply-To: <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
Message-ID: <CAAw3sASmzmcn2dfY1h3QDk1EYFkiWHUyt8jzbXYs4g8k7gS7dQ@mail.gmail.com>

Hello, thanks for reply!

There is only one time zone in Ukraine right now - Europe/Kiev (law
https://zakon.rada.gov.ua/laws/show/509-96-? paragraph 1, use Google
Translate). As for the others (Europe/Uzhgorod and Europe/Zaporozhye), I
could not find any information of them in the past. But maybe I was looking
badly, historical documents are harder to look for.

If possible, please mark these zones as inactive (if we assume that the
information in them is correct) or delete them (because they are useless
and nobody uses them). The main problem is that many third-party software
offers these zones to choose from. What is wrong because these zones do not
exist now.

PS: I am a citizen of Ukraine, so you can ask specific questions, I will
try to find answers to them. Unfortunately, I could not find Shanks's
International Atlas, therefore, I can?t verify the accuracy of the data.


??, 2 ???. 2019 ?. ? 21:31, Paul Eggert <eggert at cs.ucla.edu>:

> On 11/26/19 6:04 AM, Mikhail Gribanov wrote:
>
> >> Europe/Uzhgorod
> >> Europe/Zaporozhye
> >>
> >> Can you explain why they were added? I did not find any evidence of
> >> the existence of events "Ruthenia used CET 1990/1991" (comment in tz
> >> database).
>
> As I recall, they were added because Shanks's International Atlas had
> them. The "europe" file says:
>
> # Unless otherwise specified, the source for data through 1990 is:
> # Thomas G. Shanks and Rique Pottenger, The International Atlas (6th
> edition),
> # San Diego: ACS Publications, Inc. (2003).
> # Unfortunately this book contains many errors and cites no sources.
>
> It's quite possible that Shanks was wrong, or that I transcribed Shanks
> incorrectly. If so, it'd be helpful to provide evidence of the error, so
> that we can fix tzdb.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/8b76284a/attachment-0001.html>

From Scott.Nelson at thermeon.com  Tue Dec  3 20:36:31 2019
From: Scott.Nelson at thermeon.com (Scott Nelson)
Date: Tue, 3 Dec 2019 20:36:31 +0000
Subject: [tz] Howard Hinnant's Time Zone Database Parser
Message-ID: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>

I didn?t see a mention of Howard Hinnant?s Time Zone Database Parser (https://howardhinnant.github.io/date/tz.html); did I miss it or is it something worthwhile to add to your list on tz-link.html?
--
Scott






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/62a98e1c/attachment-0001.html>

From eggert at cs.ucla.edu  Tue Dec  3 23:09:41 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Tue, 3 Dec 2019 15:09:41 -0800
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
Message-ID: <91ffcc9a-f727-2efc-eb91-859604d11eeb@cs.ucla.edu>

On 12/3/19 12:36 PM, Scott Nelson wrote:
> I didn?t see a mention of Howard Hinnant?s Time Zone Database Parser 
> (https://howardhinnant.github.io/date/tz.html)

It's currently the 4th bullet in the "Other tz compilers" section:

https://data.iana.org/time-zones/tz-link.html#compilers

From arthurdavidolson at gmail.com  Tue Dec  3 23:12:14 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Tue, 3 Dec 2019 18:12:14 -0500
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
Message-ID: <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>

A passage from https://howardhinnant.github.io/date/tz.html that may bear
investigation appears below.

    @dashdashado

You can also customize the build by defining macros (e.g. on the command
line) as follows...

AUTO_DOWNLOAD

If AUTO_DOWNLOAD is 1 then first access to the timezone database will
install it if it hasn't been installed, and if it has, will use the remote
API to install the latest version if not already installed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/fdadd9bb/attachment.html>

From eggert at cs.ucla.edu  Tue Dec  3 23:33:52 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Tue, 3 Dec 2019 15:33:52 -0800
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
 <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>
Message-ID: <d1962d35-5d33-d46f-cc46-650e923ace83@cs.ucla.edu>

On 12/3/19 3:12 PM, Arthur David Olson wrote:

>         If |AUTO_DOWNLOAD| is |1| then first access to the timezone
>         database will install it if it hasn't been installed, and if it
>         has, will use the remote API to install the latest version if
>         not already installed.

You're right, that's somewhat concerning, as iana.org is not set up to 
handle HTTPS requests from a lot of clients. Perhaps Howard can be 
talked into making his parser's default URL point somewhere else 
(GitHub?) instead of to iana.org. I'll CC: this message to him.

Also, although that parser scrapes the current version number from 
<https://www.iana.org/time-zones>, that web page's format is not 
standardized and might change. It would be more reliable to get the 
latest version number from 
<https://data.iana.org/time-zones/data/version>, or to get the latest 
version (including its version number) from 
<https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz>.

From howard.hinnant at gmail.com  Wed Dec  4 00:04:40 2019
From: howard.hinnant at gmail.com (Howard Hinnant)
Date: Tue, 3 Dec 2019 19:04:40 -0500
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <d1962d35-5d33-d46f-cc46-650e923ace83@cs.ucla.edu>
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
 <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>
 <d1962d35-5d33-d46f-cc46-650e923ace83@cs.ucla.edu>
Message-ID: <A58BD604-14F5-47FA-A620-8F548A16376F@gmail.com>

On Dec 3, 2019, at 6:33 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> 
> On 12/3/19 3:12 PM, Arthur David Olson wrote:
> 
>>        If |AUTO_DOWNLOAD| is |1| then first access to the timezone
>>        database will install it if it hasn't been installed, and if it
>>        has, will use the remote API to install the latest version if
>>        not already installed.
> 
> You're right, that's somewhat concerning, as iana.org is not set up to handle HTTPS requests from a lot of clients. Perhaps Howard can be talked into making his parser's default URL point somewhere else (GitHub?) instead of to iana.org. I'll CC: this message to him.
> 
> Also, although that parser scrapes the current version number from <https://www.iana.org/time-zones>, that web page's format is not standardized and might change. It would be more reliable to get the latest version number from <https://data.iana.org/time-zones/data/version>, or to get the latest version (including its version number) from <https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz>.

The end-game here is this library has been voted into the C++20 working draft, to be provided by the std::lib vendors.  And without the AUTO_DOWNLOAD feature.  Each platform will provide the database as Linux/Mac/BSD do now.

http://eel.is/c++draft/#time

As C++20 becomes more available, my library will be obsoleted by the std implementation.  It is a planned obsolesce.  The AUTO_DOWNLOAD will functionality will fade into the rearview mirror.

But do be aware that the IANA timezone database (not the tools) has now effectively become the provider for an ISO standard.  So try not to get too crazy with changing things. :-)

Howard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/13b1ae49/signature.asc>

From guy at alum.mit.edu  Wed Dec  4 00:09:47 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Tue, 3 Dec 2019 16:09:47 -0800
Subject: [tz] Unnecessary time zones in Ukraine territory
In-Reply-To: <CAAw3sASmzmcn2dfY1h3QDk1EYFkiWHUyt8jzbXYs4g8k7gS7dQ@mail.gmail.com>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
 <CAAw3sASmzmcn2dfY1h3QDk1EYFkiWHUyt8jzbXYs4g8k7gS7dQ@mail.gmail.com>
Message-ID: <F9948B47-BF7A-4726-B519-233998E41DD9@alum.mit.edu>

On Dec 3, 2019, at 1:14 AM, Mikhail Gribanov <mikhail.gribanov at gmail.com> wrote:

> If possible, please mark these zones as inactive (if we assume that the information in them is correct) or delete them (because they are useless and nobody uses them).

To quote the tzdb's Theory file:

	ftp://ftp.iana.org/tz/tzdb-2018g/theory.html

"The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. It organizes time zone and daylight saving time data by partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch (1970-01-01 00:00:00 UTC). The database labels each timezone with a notable location and records all known clock transitions for that location. Although 1970 is a somewhat-arbitrary cutoff, there are significant challenges to moving the cutoff earlier even by a decade or two, due to the wide variety of local practices before computer timekeeping became prevalent.

Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone, because clocks in a timezone all agree after 1970 whereas a traditional time zone merely specifies current standard time. For example, applications that deal with current and future timestamps in the traditional North American mountain time zone can choose from the timezones America/Denver which observes US-style daylight saving time, America/Mazatlan which observes Mexican-style DST, and America/Phoenix which does not observe DST. Applications that also deal with past timestamps in the mountain time zone can choose from over a dozen timezones, such as America/Boise, America/Edmonton, and America/Hermosillo, each of which currently uses mountain time but differs from other timezones for some timestamps after 1970."

There's no notion of a zone being "inactive"; even if two different tzdb "timezones" (which I prefer to call "regions", so as not to confuse them with "traditional time zone[s]") now happen to be part of the same traditional time zone, that doesn't mean that one of them is now "inactive".

The tzdb does not exist only to allow converting the *current* time, expressed as some form of universal time (e.g., non-leap seconds that have elapsed since January 1, 1970, 00:00:00 UTC), to a local wall clock time; it also exists to convert times in the *past*:

	$ ls -l /System/Library/Kernels/kernel 
	-rwxr-xr-x  1 root  wheel  15867112 Oct 12 00:09 /System/Library/Kernels/kernel

to a wall-clock time.  The "somewhat-arbitrary" cutoff is the origin of time stamps on UN*X systems, as well as time_t in the Microsoft C library; a program storing times in that format could store a date/time going back that far, and might want to convert it to local time, so differences dating back that far could be useful (and we're not in a position to say confidently that they're not useful).

(And this is hardly unique to Ukraine - there are locations in the US that changed their "traditional time zone" in the 1990s.)

> The main problem is that many third-party software offers these zones to choose from. What is wrong because these zones do not exist now.

No, it's wrong because software shouldn't offer tzdb IDs to choose from.

If software can determine your location and find the appropriate tzdb ID for the location in a map, given the location, that's idea.  (The software running on my machine can do that - *and* if it sees that the machine has moved across tzdb ID boundaries, it updates the current local time zone setting; yes, it even does that in running processes that don't have TZ set explicitly.)

If not, then offering lists of cities, from which the user can select the nearest city, would work.

From fweimer at redhat.com  Wed Dec  4 10:25:29 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 04 Dec 2019 11:25:29 +0100
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <A58BD604-14F5-47FA-A620-8F548A16376F@gmail.com> (Howard
 Hinnant's message of "Tue, 3 Dec 2019 19:04:40 -0500")
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
 <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>
 <d1962d35-5d33-d46f-cc46-650e923ace83@cs.ucla.edu>
 <A58BD604-14F5-47FA-A620-8F548A16376F@gmail.com>
Message-ID: <87wobcpeue.fsf@oldenburg2.str.redhat.com>

* Howard Hinnant:

> The end-game here is this library has been voted into the C++20
> working draft, to be provided by the std::lib vendors.  And without
> the AUTO_DOWNLOAD feature.  Each platform will provide the database as
> Linux/Mac/BSD do now.
>
> http://eel.is/c++draft/#time
>
> As C++20 becomes more available, my library will be obsoleted by the
> std implementation.  It is a planned obsolesce.  The AUTO_DOWNLOAD will
> functionality will fade into the rearview mirror.

I think I have commented on this before.

The API assumes that time zone have names that identify them, which is
generally not true.  On GNU/Linux, the system time zone is the tzdata
blob in /etc/localtime, and you cannot in general determine a name from
that.  Particularly not a name that you can use to set TZ and get back
the same blob or even the same time zone.  I suspect we could make up a
fake name like SYSTEM for this case.

It's not clear to me whether the expected implementation of the
time_zone * object returned from tzdb::current_zone() is one that
automatically reloads time zone information as it becomes available
(like the POSIX interfaces on GNU/Linux do).  In other words, there is
no need for reload_tzdb() to do anything in order to update the current
time zone data in a process.

The definition of struct tzdb with its public data members is really
strange.  Is it expected that in order to look up leap seconds,
applications look at leap vector?  Then it is impossible to implement
automatic reloading of leap seconds, which would be disappointing.

Thanks,
Florian


From skeet at pobox.com  Thu Dec  5 08:03:51 2019
From: skeet at pobox.com (Jon Skeet)
Date: Thu, 5 Dec 2019 08:03:51 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <CA+5fHtLueYNiJjxXdPq-7vJQwOS=EBFjEkBQMAYPOWptD0PK0g@mail.gmail.com>

On Thu, 5 Dec 2019 at 02:07, Benjamin Weiser <Benjamin.Weiser at inrix.com>
wrote:

> I do see a lot of these have recently updated.
>
>
>
> I still see an issue with Brazil. Are those to be assumed as updated as
> well? I?m still seeing, for example in America/Sao_Paulo:
>
>
>
> Zone America/Sao_Paulo             -3:06:28 -             LMT       1914
>
>                                                 -3:00      Brazil
> -03/-02 1963 Oct 23  0:00
>
>                                                 -3:00      1:00
> -02          1964
>
>                                                 -3:00      Brazil
> -03/-02
>
>
>
> The last line would indicate that its still following daylight savings,
> which Brazil scrapped this year.
>
>  -3:00     Brazil     -03/-02
>

No, that just means that since 1964, Sao_Paulo followed the Brazil rules.

The Brazil rules have no DST changes after 2019-02-17T02:00:00Z. See
https://nodatime.org/tzvalidate/generate?version=2019c&zone=America/Sao_Paulo

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191205/a17c0176/attachment.html>

From eggert at cs.ucla.edu  Fri Dec  6 04:34:31 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Thu, 5 Dec 2019 20:34:31 -0800
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
Message-ID: <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>

On 12/4/19 1:04 PM, Michael Veth wrote:

> The NIST leapsecond bulletin includes an expiration time which serves to 
> indicate the maximum validity?interval for use of UTC time.? In order to 
> safely use UTC timestamps, the user needs to be aware of this maximum 
> validity time or they could be unknowingly introducing timing errors.
> 
> I was not able to find this field in the TZif (Feb 19) ICD.? Would it be 
> possible to add a field to the TZdb that would represent this expiration 
> time?

The TZif file format does provide for truncated files (see Internet RFC 
8536 section 5.1), and one can generate files truncated to the current 
UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this:

zic -r /@1593302427 -L leapseconds tzdata.zi

However, it's awkward that one must count the number of seconds since 
1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the 
numeric timestamp (1593302427 in this case) to pass to zic. We could add 
support to zic to do this sort of thing in a more-natural way.

A downside of the abovementioned approach is that it generates a TZif 
file that omits all DST and time zone transitions after the UTC 
expiration time. We could change the TZif format to represent UTC 
expiration time separately from the truncation time. One possibility 
would be to append a leap-second record with an "occur" value equal to 
the expiration time and a "corr" value equal to the previous record's 
"corr" value. Strictly speaking this would violate RFC 8536 section 3.2 
"leap-second records" - though I doubt whether many clients would care - 
and so I suppose we'd need to increment the TZif format version number 
from 3 to 4. On the other hand, any files generated by this method would 
continue to be "incorrect" in that they'd continue to predict timestamps 
past the maximum leap second validity, so perhaps it wouldn't be worth 
going to all this work to generate "incorrect" files.

I'll cc this to tz at iana.org and tzdist-bis at ietf.org to see whether 
anybody there cares to comment.

From arthurdavidolson at gmail.com  Fri Dec  6 05:09:46 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Fri, 6 Dec 2019 00:09:46 -0500
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
Message-ID: <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>

One odd possibility below.

    @dashdashado

Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28
                        0       -       POST

On Thu, Dec 5, 2019 at 11:34 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/4/19 1:04 PM, Michael Veth wrote:
>
> > The NIST leapsecond bulletin includes an expiration time which serves to
> > indicate the maximum validity interval for use of UTC time.  In order to
> > safely use UTC timestamps, the user needs to be aware of this maximum
> > validity time or they could be unknowingly introducing timing errors.
> >
> > I was not able to find this field in the TZif (Feb 19) ICD.  Would it be
> > possible to add a field to the TZdb that would represent this expiration
> > time?
>
> The TZif file format does provide for truncated files (see Internet RFC
> 8536 section 5.1), and one can generate files truncated to the current
> UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this:
>
> zic -r /@1593302427 -L leapseconds tzdata.zi
>
> However, it's awkward that one must count the number of seconds since
> 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the
> numeric timestamp (1593302427 in this case) to pass to zic. We could add
> support to zic to do this sort of thing in a more-natural way.
>
> A downside of the abovementioned approach is that it generates a TZif
> file that omits all DST and time zone transitions after the UTC
> expiration time. We could change the TZif format to represent UTC
> expiration time separately from the truncation time. One possibility
> would be to append a leap-second record with an "occur" value equal to
> the expiration time and a "corr" value equal to the previous record's
> "corr" value. Strictly speaking this would violate RFC 8536 section 3.2
> "leap-second records" - though I doubt whether many clients would care -
> and so I suppose we'd need to increment the TZif format version number
> from 3 to 4. On the other hand, any files generated by this method would
> continue to be "incorrect" in that they'd continue to predict timestamps
> past the maximum leap second validity, so perhaps it wouldn't be worth
> going to all this work to generate "incorrect" files.
>
> I'll cc this to tz at iana.org and tzdist-bis at ietf.org to see whether
> anybody there cares to comment.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191206/c28607d2/attachment.html>

From michael.h.deckers at googlemail.com  Fri Dec  6 11:48:47 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Fri, 6 Dec 2019 11:48:47 +0000
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
 <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
Message-ID: <b83f4bde-dfa1-5434-c181-3384fdf73a1b@googlemail.com>


 ?? On 2019-12-06, Arthur David Olson proposed
 ?? a method to expose in TZif the expiration date
 ?? of the leap second information:


> One odd possibility below.
>
>      @dashdashado
>
> Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28
>                          0       -       POST
>


 ?? Why not produce a tzdb Zone for TAI? As if we had

 ?????? Zone??? Etc/TAI? 0:00:10 -????? TAI???? 1972 Jul? 1
 ??????????????????????? 0:00:11 -????? TAI???? 1973 Jan? 1
 ??????????????????????? ....
 ??????????????????????? 0:00:35 -????? TAI???? 2015 Jul? 1
 ??????????????????????? 0:00:36 -????? TAI???? 2017 Jan? 1
 ??????????????????????? 0:00:37 -????? TAI???? 2020 Jun 28
 ??????????????????????? 0:00:37 -????? N_A

 ?? After all, the Bulletins C of the IERS specify TAI as
 ?? a function of UTC, just like a tzdb "timezone".

 ?? Michael Deckers.


From Benjamin.Weiser at inrix.com  Thu Dec  5 02:07:14 2019
From: Benjamin.Weiser at inrix.com (Benjamin Weiser)
Date: Thu, 5 Dec 2019 02:07:14 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>

I do see a lot of these have recently updated.

I still see an issue with Brazil. Are those to be assumed as updated as well? I?m still seeing, for example in America/Sao_Paulo:

Zone America/Sao_Paulo             -3:06:28 -             LMT       1914
                                                -3:00      Brazil     -03/-02 1963 Oct 23  0:00
                                                -3:00      1:00        -02          1964
                                                -3:00      Brazil     -03/-02

The last line would indicate that its still following daylight savings, which Brazil scrapped this year.
 -3:00     Brazil     -03/-02

From: Benjamin Weiser
Sent: Monday, December 2, 2019 10:59 AM
To: Jon Skeet <skeet at pobox.com>
Cc: tz at iana.org
Subject: RE: [tz] incorrect timezone info from tar files

Thank you Jon,

I will have the dev take a look at why his tools are not refreshing the data correctly.  I do see the correct values in the links that you provided and in the download I mentioned. We were in the process of consolidating two teams that were sourcing TimeZones from different data sources. The team using IANA was claiming they were refreshing, so something must be going wrong with their tools as you suggested.

I appreciate the feedback.

From: Jon Skeet <skeet at pobox.com<mailto:skeet at pobox.com>>
Sent: Monday, December 2, 2019 9:49 AM
To: Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>>
Cc: tz at iana.org<mailto:tz at iana.org>
Subject: Re: [tz] incorrect timezone info from tar files

Could you clarify exactly how you derived your table, in terms of the IANA data?

If you look at https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnodatime.org%2Ftzvalidate%2Fgenerate%3Fversion%3D2019c%26zone%3DEurope%2FIstanbul&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446283964&sdata=Z0%2Bx2yU00vEkAzTGo5Ur7NHttfjLRqsgX2y4E7j0dMg%3D&reserved=0> - which is generated from IANA data - it shows DST changes stopping in September 2016, just as you said.

Likewise if you look at the current source data<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feggert%2Ftz%2Fblob%2F1a27ec76bc436a64070461bbbf28e0511c7cf3b8%2Feurope%23L3889&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446288944&sdata=%2Bs4k7r5pNGwBw0lhOUEIcDYUrxWsKxdR2j5H7VWkXnI%3D&reserved=0>, you'll see the same result.

I suspect this is a problem of data interpretation rather than anything else.

Jon


On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:
Hello,

I?d like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Ftime-zones&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446293919&sdata=E4593Nqq4EaQadhjoAmDv7Ww9oy%2F2YcO7ByNps5SYA4%3D&reserved=0>

For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST.

I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST)


TimeZone
UTC Offset
ObservesDST
IANA_UTC_offset:
IANA_ObservesDST:
America/Campo_Grande
-4
0
-4
1
America/Sao_Paulo
-3
0
-3
1
America/St_Johns
-3.5
1
-3
1
Asia/Sakhalin
11
0
10
0
Australia/Adelaide
9.5
1
9
1
Australia/Darwin
9.5
0
9
0
Australia/Lord_Howe
10.5
1
10
1
Europe/Istanbul
3
0
2
1
Indian/Cocos
6.5
0
6
0
Pacific/Chatham
12.75
1
12
1

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191205/526d8641/attachment-0001.html>

From webmaster at unitconverter.net  Fri Dec  6 05:27:49 2019
From: webmaster at unitconverter.net (LISA - Unit Converter)
Date: Fri, 6 Dec 2019 05:27:49 +0000
Subject: [tz] Link Suggestion for your Website Resources page
Message-ID: <1581552221.1077255.1575610057569@ip-10-1-0-82.ec2.internal>

Dear Webmaster,

As I?m sure you?re quite busy, I?ll be quick. I just check out your resource page https://data.iana.org/time-zones/code/tz-link.html. I love your posting. Great stuff!

I wanted to share some of my work with you. We have developed a site https://unitconverter.net/time-converter. Almost we cover all kinds of time conversion and calculation. I'm sure our tool is fit for your resource page.

I am hoping you will consider our tool, it will be a great appreciation for us.

Please add our tag as " Time Converter".

Feel free to reach out. And as always, I will continue to visit your website and stay current with your business. Also Please let me know if I can do anything in the future...

Kind Regards,

Lisa Grace.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191206/e507fa14/attachment.html>

From steffen at sdaoden.eu  Fri Dec  6 17:35:30 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 06 Dec 2019 18:35:30 +0100
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <b83f4bde-dfa1-5434-c181-3384fdf73a1b@googlemail.com>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
 <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
 <b83f4bde-dfa1-5434-c181-3384fdf73a1b@googlemail.com>
Message-ID: <20191206173530.K2xlg%steffen@sdaoden.eu>

Michael H Deckers via tz wrote in <b83f4bde-dfa1-5434-c181-3384fdf73a1b@\
googlemail.com>:
 | ?? On 2019-12-06, Arthur David Olson proposed
 | ?? a method to expose in TZif the expiration date
 | ?? of the leap second information:
 |
 |> One odd possibility below.
 |>
 |>      @dashdashado
 |>
 |> Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28
 |>                          0       -       POST
 |>
 |
 | ?? Why not produce a tzdb Zone for TAI? As if we had
 |
 | ?????? Zone??? Etc/TAI? 0:00:10 -????? TAI???? 1972 Jul? 1
 | ??????????????????????? 0:00:11 -????? TAI???? 1973 Jan? 1
 | ??????????????????????? ....
 | ??????????????????????? 0:00:35 -????? TAI???? 2015 Jul? 1
 | ??????????????????????? 0:00:36 -????? TAI???? 2017 Jan? 1
 | ??????????????????????? 0:00:37 -????? TAI???? 2020 Jun 28
 | ??????????????????????? 0:00:37 -????? N_A
 |
 | ?? After all, the Bulletins C of the IERS specify TAI as
 | ?? a function of UTC, just like a tzdb "timezone".

That is a great idea!  What i always missed with UTC and leap
seconds, or say, time keeping as you get it on a Unix system out
of the box, is the difference to TAI, that is, the number of leap
seconds.  You could even do calendar stuff with seconds if you had
that possibility.  At least a bit.  But anyway it would be
possible to notify the occurrence of a leap second even after it
had happened, out of the box.
Interesting.  I never thought of that possibility.  It does not
seem to fit right/ ;).

 | ?? Michael Deckers.
 |
 --End of <b83f4bde-dfa1-5434-c181-3384fdf73a1b at googlemail.com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From madigo at gmail.com  Fri Dec  6 20:55:35 2019
From: madigo at gmail.com (=?UTF-8?Q?Rodrigo_Br=C3=BCning_Wessler?=)
Date: Fri, 6 Dec 2019 17:55:35 -0300
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>

Brazilian time zone rules was updated and released in version 2019b.

I'm using this version without issues.

On Fri, Dec 6, 2019 at 5:28 PM Benjamin Weiser <Benjamin.Weiser at inrix.com>
wrote:

> I do see a lot of these have recently updated.
>
>
>
> I still see an issue with Brazil. Are those to be assumed as updated as
> well? I?m still seeing, for example in America/Sao_Paulo:
>
>
>
> Zone America/Sao_Paulo             -3:06:28 -             LMT       1914
>
>                                                 -3:00      Brazil
> -03/-02 1963 Oct 23  0:00
>
>                                                 -3:00      1:00
> -02          1964
>
>                                                 -3:00      Brazil
> -03/-02
>
>
>
> The last line would indicate that its still following daylight savings,
> which Brazil scrapped this year.
>
>  -3:00     Brazil     -03/-02
>
>
>
> *From:* Benjamin Weiser
> *Sent:* Monday, December 2, 2019 10:59 AM
> *To:* Jon Skeet <skeet at pobox.com>
> *Cc:* tz at iana.org
> *Subject:* RE: [tz] incorrect timezone info from tar files
>
>
>
> Thank you Jon,
>
>
>
> I will have the dev take a look at why his tools are not refreshing the
> data correctly.  I do see the correct values in the links that you provided
> and in the download I mentioned. We were in the process of consolidating
> two teams that were sourcing TimeZones from different data sources. The
> team using IANA was claiming they were refreshing, so something must be
> going wrong with their tools as you suggested.
>
>
>
> I appreciate the feedback.
>
>
>
> *From:* Jon Skeet <skeet at pobox.com>
> *Sent:* Monday, December 2, 2019 9:49 AM
> *To:* Benjamin Weiser <Benjamin.Weiser at inrix.com>
> *Cc:* tz at iana.org
> *Subject:* Re: [tz] incorrect timezone info from tar files
>
>
>
> Could you clarify *exactly *how you derived your table, in terms of the
> IANA data?
>
>
>
> If you look at
> https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnodatime.org%2Ftzvalidate%2Fgenerate%3Fversion%3D2019c%26zone%3DEurope%2FIstanbul&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446283964&sdata=Z0%2Bx2yU00vEkAzTGo5Ur7NHttfjLRqsgX2y4E7j0dMg%3D&reserved=0> -
> which is generated from IANA data - it shows DST changes stopping in
> September 2016, just as you said.
>
>
>
> Likewise if you look at the current source data
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feggert%2Ftz%2Fblob%2F1a27ec76bc436a64070461bbbf28e0511c7cf3b8%2Feurope%23L3889&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446288944&sdata=%2Bs4k7r5pNGwBw0lhOUEIcDYUrxWsKxdR2j5H7VWkXnI%3D&reserved=0>,
> you'll see the same result.
>
>
>
> I suspect this is a problem of data interpretation rather than anything
> else.
>
>
>
> Jon
>
>
>
>
>
> On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com>
> wrote:
>
> Hello,
>
>
>
> I?d like to report your downloads for the following Time Zones from this
> URL on your site are out of date: https://www.iana.org/time-zones
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Ftime-zones&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446293919&sdata=E4593Nqq4EaQadhjoAmDv7Ww9oy%2F2YcO7ByNps5SYA4%3D&reserved=0>
>
>
>
> For instance Europe/Istanbul moved to UTC 3 permanently in September of
> 2016 and no longer follow DST.
>
>
>
> I will place the correct times first, and then the incorrect IANA times
> second. Highlighted in orange have the incorrect time zone information (0
> means there is no DST, 1 means they follow DST)
>
>
>
>
>
> TimeZone
>
> UTC Offset
>
> ObservesDST
>
> IANA_UTC_offset:
>
> IANA_ObservesDST:
>
> America/Campo_Grande
>
> -4
>
> 0
>
> -4
>
> 1
>
> America/Sao_Paulo
>
> -3
>
> 0
>
> -3
>
> 1
>
> America/St_Johns
>
> -3.5
>
> 1
>
> -3
>
> 1
>
> Asia/Sakhalin
>
> 11
>
> 0
>
> 10
>
> 0
>
> Australia/Adelaide
>
> 9.5
>
> 1
>
> 9
>
> 1
>
> Australia/Darwin
>
> 9.5
>
> 0
>
> 9
>
> 0
>
> Australia/Lord_Howe
>
> 10.5
>
> 1
>
> 10
>
> 1
>
> Europe/Istanbul
>
> 3
>
> 0
>
> 2
>
> 1
>
> Indian/Cocos
>
> 6.5
>
> 0
>
> 6
>
> 0
>
> Pacific/Chatham
>
> 12.75
>
> 1
>
> 12
>
> 1
>
>
>
> Thanks.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191206/895e3822/attachment-0001.html>

From guy at alum.mit.edu  Fri Dec  6 21:44:26 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Fri, 6 Dec 2019 13:44:26 -0800
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <5AB28AAF-23B4-4557-B642-0218B51FBAB2@alum.mit.edu>

On Dec 4, 2019, at 6:07 PM, Benjamin Weiser <Benjamin.Weiser at inrix.com> wrote:

> I still see an issue with Brazil. Are those to be assumed as updated as well? I?m still seeing, for example in America/Sao_Paulo:
> 
>  
> 
> Zone America/Sao_Paulo             -3:06:28   -          LMT       1914
>                                    -3:00      Brazil     -03/-02   1963 Oct 23  0:00
>                                    -3:00      1:00       -02       1964
>                                    -3:00      Brazil     -03/-02
> 
> The last line would indicate that its still following daylight savings, which Brazil scrapped this year.

No, it doesn't.  It says that it's following the "Brazil" rules, which are, in the 2019b and 2019c releases:

	...

Rule	Brazil	2008	2017	-	Oct	Sun>=15	0:00	1:00	-
Rule	Brazil	2008	2011	-	Feb	Sun>=15	0:00	0	-
Rule	Brazil	2012	only	-	Feb	Sun>=22	0:00	0	-
Rule	Brazil	2013	2014	-	Feb	Sun>=15	0:00	0	-
Rule	Brazil	2015	only	-	Feb	Sun>=22	0:00	0	-
Rule	Brazil	2016	2019	-	Feb	Sun>=15	0:00	0	-
Rule	Brazil	2018	only	-	Nov	Sun>=1	0:00	1:00	-

which says that (among other things, but I omitted the earlier rules that go back to 1931):

	on the third Sunday in October 2008-2017, the clocks are set forward to 1 hour ahead of standard time;

	on the third Sunday in February 2008-2011, the clocks are set backward to standard time;

	on the fourth Sunday in February 2012, the clocks are set backward to standard time;

	on the third Sunday in February 2013-2014, the clocks are set backward to standard time;

	on the fourth Sunday in February 2015, the clocks are set to standard time;

	on the third Sunday in February 2016-2019, the clocks are set to standard time;

	on the first Sunday in November 2018, the clocks are set forward to 1 hour ahead of standard time;

so they got set to standard time on 2019-02-17 and have not been set forward since - in particular, they were not set forward in November.

From eggert at cs.ucla.edu  Fri Dec  6 21:45:22 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Fri, 6 Dec 2019 13:45:22 -0800
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
 <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
Message-ID: <5397b1f1-7db6-e190-f978-4f8dda59d67f@cs.ucla.edu>

On 12/5/19 9:09 PM, Arthur David Olson wrote:

> Zone ? ?Etc/Leapendstat 0 ? ? ? - ? ? ? PRE ? ? 2020 Jun 28
>  ? ? ? ? ? ? ? ? ? ? ? ? 0 ? ? ? - ? ? ? POST

Although that would let someone determine leap second validity by 
examining a different file (or issuing another TZDIST request), Michael 
Veth was asking for a way to determine leap second validity by examining 
the same TZif file that contains the leap-second records.

On 12/6/19 3:48 AM, Michael H Deckers wrote:

>    Why not produce a tzdb Zone for TAI? As if we had
> 
>        Zone    Etc/TAI  0:00:10 -      TAI     1972 Jul  1
>                         0:00:11 -      TAI     1973 Jan  1
>                         ....
>                         0:00:35 -      TAI     2015 Jul  1
>                         0:00:36 -      TAI     2017 Jan  1
>                         0:00:37 -      TAI     2020 Jun 28
>                         0:00:37 -      N_A 

This won't have the desired effect. For example, it would cause the 
Etc/TAI clock's adjacent ticks to be 1972-06-30 23:59:59 and 1972-07-01 
00:00:01, whereas the adjacent ticks should be 1972-06-30 23:59:60 and 
1972-07-01 00:00:00. Also, when compiling the Etc/TAI zone with -L 
leapseconds, the resulting TZif file would have incorrect transitions 
because each leap second would be applied twice.

From mj1856 at hotmail.com  Sat Dec  7 01:12:34 2019
From: mj1856 at hotmail.com (Matt Johnson-Pint)
Date: Sat, 7 Dec 2019 01:12:34 +0000
Subject: [tz] Link Suggestion for your Website Resources page
In-Reply-To: <1581552221.1077255.1575610057569@ip-10-1-0-82.ec2.internal>
References: <1581552221.1077255.1575610057569@ip-10-1-0-82.ec2.internal>
Message-ID: <BYAPR06MB3879F72F027C338B6464B33DC25E0@BYAPR06MB3879.namprd06.prod.outlook.com>

How do I downvote here?
________________________________
From: tz <tz-bounces at iana.org> on behalf of LISA - Unit Converter <webmaster at unitconverter.net>
Sent: Friday, December 6, 2019 6:27:49 AM
To: tz at iana.org <tz at iana.org>
Subject: [tz] Link Suggestion for your Website Resources page


Dear Webmaster,

As I?m sure you?re quite busy, I?ll be quick. I just check out your resource page https://data.iana.org/time-zones/code/tz-link.html. I love your posting. Great stuff!

I wanted to share some of my work with you. We have developed a site https://unitconverter.net/time-converter. Almost we cover all kinds of time conversion and calculation. I'm sure our tool is fit for your resource page.

I am hoping you will consider our tool, it will be a great appreciation for us.

Please add our tag as " Time Converter".

Feel free to reach out. And as always, I will continue to visit your website and stay current with your business. Also Please let me know if I can do anything in the future...

Kind Regards,

Lisa Grace.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191207/bf147951/attachment.html>

From michael.h.deckers at googlemail.com  Sat Dec  7 01:15:26 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Sat, 7 Dec 2019 01:15:26 +0000
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <5397b1f1-7db6-e190-f978-4f8dda59d67f@cs.ucla.edu>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
 <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
 <5397b1f1-7db6-e190-f978-4f8dda59d67f@cs.ucla.edu>
Message-ID: <c85e1997-2177-1b79-b400-b73037d338f7@googlemail.com>


On 2019-12-06 21:45, Paul Eggert wrote:

> This won't have the desired effect. For example, it would cause the 
> Etc/TAI clock's adjacent ticks to be 1972-06-30 23:59:59 and 
> 1972-07-01 00:00:01, whereas the adjacent ticks should be 1972-06-30 
> 23:59:60 and 1972-07-01 00:00:00. Also, when compiling the Etc/TAI 
> zone with -L leapseconds, the resulting TZif file would have incorrect 
> transitions because each leap second would be applied twice.


 ???? Oops -- I should not have omitted the time of day of
 ???? the switches from the Zone lines -- sorry for the confusion.

 ???? The complete lines must have a time of day, of course:

 ??????? Zone?? Etc/TAI? 0:00:10 - TAI?? 1972 Jul? 1? 0:00:00u
 ??????????????????????? 0:00:11 - TAI?? 1973 Jan? 1? 0:00:00u
 ??????????????????????? ....
 ??????????????????????? 0:00:35 - TAI?? 2015 Jul? 1? 0:00:00u
 ??????????????????????? 0:00:36 - TAI?? 2017 Jan? 1? 0:00:00u
 ??????????????????????? 0:00:37 - TAI?? 2020 Jun 28? 0:00:00u
 ??????????????????????? 0:00:37 - N_A

 ???? So the "adjacent ticks" you mention are in fact
 ???? the TAI values 1972-07-01T00:00:09 for UTC = 1972-06-30T23:59:59Z
 ??????????????? and 1972-07-01T00:00:11 for UTC = 1972-07-01T00:00:00Z.
 ???? Of course, these ticks of TAI are not adjacent: the TAI value
 ???? 1972-07-01T00:00:10 in between belongs to the leap second
 ???? UTC = 1972-06-30T23:59:60Z.

 ???? The Zone lines for right/Etc/TAI would give TAI as a function of
 ???? TAI - 10 s, so they would get the constant STDOFF value 0:00:10.
 ???? (And, yes, in this case the STDOFF value after 2020-06-28 is known.)

 ???? That TAI can be considered as a tzdb "timezone" is an observation
 ???? by Steve Allen, if I remember correctly.

 ???? Michael Deckers.


From eggert at cs.ucla.edu  Sat Dec  7 01:21:35 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Fri, 6 Dec 2019 17:21:35 -0800
Subject: [tz] Link Suggestion for your Website Resources page
In-Reply-To: <BYAPR06MB3879F72F027C338B6464B33DC25E0@BYAPR06MB3879.namprd06.prod.outlook.com>
References: <1581552221.1077255.1575610057569@ip-10-1-0-82.ec2.internal>
 <BYAPR06MB3879F72F027C338B6464B33DC25E0@BYAPR06MB3879.namprd06.prod.outlook.com>
Message-ID: <0e0a21a0-2719-2921-b955-cb08852038ef@cs.ucla.edu>

I replied privately that the link doesn't seem appropriate for us.

From Benjamin.Weiser at inrix.com  Fri Dec  6 21:23:41 2019
From: Benjamin.Weiser at inrix.com (Benjamin Weiser)
Date: Fri, 6 Dec 2019 21:23:41 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
Message-ID: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>

Thanks Rodrigo,

Do you mind explaining how you would parse America/Sao_Paulo? I see the note acknowledging Daylight Savings was scrapped, but not sure how you are getting that value correctly.

We are using a JODA library, and my understanding is it finds the timezone under the ?Zone? section, such as America/Sao_Paulo, and finds the bottom most value for the most current timezone.

For America/Sao_Paulo it says:
-3:00      Brazil     -03/-02

Are we not looking in the correct place?  In the ?Rule? section I don?t see anything that would give me -3:00 without DST.

Thanks

From: Rodrigo Br?ning Wessler <madigo at gmail.com>
Sent: Friday, December 6, 2019 12:56 PM
To: Benjamin Weiser <Benjamin.Weiser at inrix.com>
Cc: Jon Skeet <skeet at pobox.com>; tz at iana.org
Subject: Re: [tz] incorrect timezone info from tar files

Brazilian time zone rules was updated and released in version 2019b.

I'm using this version without issues.

On Fri, Dec 6, 2019 at 5:28 PM Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:
I do see a lot of these have recently updated.

I still see an issue with Brazil. Are those to be assumed as updated as well? I?m still seeing, for example in America/Sao_Paulo:

Zone America/Sao_Paulo             -3:06:28 -             LMT       1914
                                                -3:00      Brazil     -03/-02 1963 Oct 23  0:00
                                                -3:00      1:00        -02          1964
                                                -3:00      Brazil     -03/-02

The last line would indicate that its still following daylight savings, which Brazil scrapped this year.
 -3:00     Brazil     -03/-02

From: Benjamin Weiser
Sent: Monday, December 2, 2019 10:59 AM
To: Jon Skeet <skeet at pobox.com<mailto:skeet at pobox.com>>
Cc: tz at iana.org<mailto:tz at iana.org>
Subject: RE: [tz] incorrect timezone info from tar files

Thank you Jon,

I will have the dev take a look at why his tools are not refreshing the data correctly.  I do see the correct values in the links that you provided and in the download I mentioned. We were in the process of consolidating two teams that were sourcing TimeZones from different data sources. The team using IANA was claiming they were refreshing, so something must be going wrong with their tools as you suggested.

I appreciate the feedback.

From: Jon Skeet <skeet at pobox.com<mailto:skeet at pobox.com>>
Sent: Monday, December 2, 2019 9:49 AM
To: Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>>
Cc: tz at iana.org<mailto:tz at iana.org>
Subject: Re: [tz] incorrect timezone info from tar files

Could you clarify exactly how you derived your table, in terms of the IANA data?

If you look at https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnodatime.org%2Ftzvalidate%2Fgenerate%3Fversion%3D2019c%26zone%3DEurope%2FIstanbul&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7C6ce9b6589b6c4178083e08d77a8eac54%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C0%7C637112625523354252&sdata=EyV738S01v1f8M%2Bv6W3GWJSsN5Gm85dDGMgkw12wt60%3D&reserved=0> - which is generated from IANA data - it shows DST changes stopping in September 2016, just as you said.

Likewise if you look at the current source data<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feggert%2Ftz%2Fblob%2F1a27ec76bc436a64070461bbbf28e0511c7cf3b8%2Feurope%23L3889&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7C6ce9b6589b6c4178083e08d77a8eac54%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C0%7C637112625523364245&sdata=2OZzzLrWNzNYo1v8pbs0BJIJ5hnVfiuoP60BsqLyiM4%3D&reserved=0>, you'll see the same result.

I suspect this is a problem of data interpretation rather than anything else.

Jon


On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:
Hello,

I?d like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Ftime-zones&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7C6ce9b6589b6c4178083e08d77a8eac54%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C0%7C637112625523364245&sdata=APGcT40OlXZM1HF%2Fty%2FrAV9IbLdxe39xZDdOAuy7BZY%3D&reserved=0>

For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST.

I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST)


TimeZone
UTC Offset
ObservesDST
IANA_UTC_offset:
IANA_ObservesDST:
America/Campo_Grande
-4
0
-4
1
America/Sao_Paulo
-3
0
-3
1
America/St_Johns
-3.5
1
-3
1
Asia/Sakhalin
11
0
10
0
Australia/Adelaide
9.5
1
9
1
Australia/Darwin
9.5
0
9
0
Australia/Lord_Howe
10.5
1
10
1
Europe/Istanbul
3
0
2
1
Indian/Cocos
6.5
0
6
0
Pacific/Chatham
12.75
1
12
1

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191206/1d56b66b/attachment-0001.html>

From eggert at cs.ucla.edu  Sat Dec  7 09:39:25 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Sat, 7 Dec 2019 01:39:25 -0800
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
 <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
Message-ID: <784a4867-6b1a-a731-9c05-b7804ef4a71f@cs.ucla.edu>

On 12/6/19 1:23 PM, Benjamin Weiser wrote:
> In the ?Rule? section I don?t see anything that would give me -3:00 without DST.

It sounds like you're looking at it backwards. There's nothing in the "Rule
Brazil" section that will give DST after February 2019. So there's no DST after
February 2019.

From kre at munnari.OZ.AU  Sat Dec  7 11:39:57 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Sat, 07 Dec 2019 18:39:57 +0700
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
References: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
 <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
Message-ID: <4667.1575718797@jinx.noi.kre.to>

    Date:        Fri, 6 Dec 2019 21:23:41 +0000
    From:        Benjamin Weiser <Benjamin.Weiser at inrix.com>
    Message-ID:  <BYAPR14MB30633C1E816B79A2B5935F18E85F0 at BYAPR14MB3063.namprd14.prod.outlook.com>

What may be confusing here, is that what this says:

	For America/Sao_Paulo it says:
	-3:00      Brazil     -03/-02

is that for Sao Paulo (for the timezone we call America/Sao_Paulo) the
standard offset from UTC is -3:00 (3 hours west of Greenwich), when
summer time applies is governed by the "Brazil" rules, and the names
of the time (the abbreviations used) are "-03" when it is not summer
time, and "-02" when it is summer time (like EST and EDT in the US).

That's important, the -03/-02 are *not* UTC offsets, they are labels.

A few years ago this might have instead been something like

	-3:00      Brazil     EBRT/EBRST

using (most probably not those) invented names for the time in winter/summer.
But many of the invented names were removed, and replaced by simple
numeric names that indicate what offset is applying - but they are
just names (labels), they specify nothing else.

That a name exists to label summer time when it applies, does not mean it
ever does, and more likely, does not mean it applies any particular year.
Those names are used for times in the past when summer time was used
(and perhaps again in the future if summer time turns on again.)

This is another important thing to remember - time conversions must
work correctly for times in the past, not just the time today.  If I
ask what time it was in Sao Paulo at 11:30 Dec 7 2018 UTC, then I
need to get the conversion done knowing that it was summer time then.
That summer time is not being used this summer does not mean it was
not used last summer, and that the answer to that question would be
different if the year requested was 2019 instead of 2018 simply
reflects how the rules are different this year than they were last year.

The only way to discover if (and if so, when) summer time turns on
and off, in this case is to look at the Brazil rules (elsewhere in the
same source file).

The relevant (recent) rules for Brazil end with (all the comments deleted):

Rule    Brazil  2008    2017    -       Oct     Sun>=15 0:00    1:00    -
Rule    Brazil  2008    2011    -       Feb     Sun>=15 0:00    0       -
Rule    Brazil  2012    only    -       Feb     Sun>=22 0:00    0       -
Rule    Brazil  2013    2014    -       Feb     Sun>=15 0:00    0       -  
Rule    Brazil  2015    only    -       Feb     Sun>=22 0:00    0       -
Rule    Brazil  2016    2019    -       Feb     Sun>=15 0:00    0       -
Rule    Brazil  2018    only    -       Nov     Sun>=1  0:00    1:00    -

The first and last of those are the only ones (shown) that enable summer
time (there are of course others for earlier years, but they're not
relevant here, so I didn't include them).

The first (as it indicates) applied from 2008 to 2017.   The last applied
in 2018 (only).   There is no rule there for turning on summer time in
2019, or any later year.

The intervening rules are all for when summer time turned off in the
various years during this period.  The last of those says summer time
(the one that started in early November 2018) ended in mid February, 2019
(as it had in most of the years since 2008, just 2012 and 2015 ended a
week later)   All of this is visible in those Rule lines.

After that there is nothing.   Summer time turned off in Feb 2019, and
never turns on again (and so never needs to turn off again either).
That is, until the politicians in Brazil decide to change things again,
in which case, after we find out what the new rules will be, we will
need a new release of tzdata to contain that new information.

The Rules are used because there are many different timezones in
Brazil, with different UTC offsets, and different labels to name
what the time is called (for whatever that is worth), but they all
turn summer time on and off (when they use it at all) according to
the same rules - so the rules are specified once, and the zones which
have summer time just reference them.   Zones in Brazil which never
use(d) summer time would not reference the Brazil rules, but simply
specify what UTC offset applies, and what to label the time as.

There aren't, but could be, some zones in Brazil which used a
different set of rules, than the others (turned summer time on
and off on different dates).  If that were the case, then there
would be another set of rules (perhaps "Brazil2" or "Tropical-Brazil"
or "Northern-Brazil" depending on what seemed appropriate) to
specify those different rules, and the relevant zones would refer
to those - that happens in Australia, where the various states
do whatever they like in this area, and while they seem to all be
in sync right now (for those states which use summer time), they haven't
been in the past.   So in AU, each state gets its own set of rules (they
cannot be combined, ever, regardless of the current rules all being
the same, or conversions of times in the past would not be correct).

Other zones (not from Brazil), which have their own unique summer time
rules, not shared with any other zones, might not bother with separate
rules and simply specify the transitions in the zone definition.

Unless you are used to reading the tzdb data source files, it is generally
best not to try - instead run a tzdb compiler (like zic) and then dump
the binary format files, and see when the transitions actually occur.
That's a much much more reliable way of verifying the data then guessing
at how to interpret the tzdata sources.

kre


From guy at alum.mit.edu  Sun Dec  8 03:44:44 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sat, 7 Dec 2019 19:44:44 -0800
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
 <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
Message-ID: <BA998194-BC78-42C1-BA82-0E4316B43FE3@alum.mit.edu>

On Dec 6, 2019, at 1:23 PM, Benjamin Weiser <Benjamin.Weiser at inrix.com> wrote:

> Do you mind explaining how you would parse America/Sao_Paulo?

Zone America/Sao_Paulo            -3:06:28   -          LMT       1914
                                  -3:00      Brazil     -03/-02   1963 Oct 23  0:00
                                  -3:00      1:00       -02       1964
                                  -3:00      Brazil     -03/-02

This says:

	Until 1914, America/Sao_Paulo is 3 hours, 6 minutes, and 28 seconds behind GMT, I guess - that's local mean time, "LMT", and labeled as such;

	from 1914 to 1963-10-23, it follows the "Brazil" rules for summer/daylight saving time, with it being 3 hours behind GMT/UTC when summer time is not in effect and 2 hours behind GMT/UTC when summer time is in effect;

	from 1963-10-23 to 1964-01-01, its time is 1 hour ahead of standard time, i.e. 2 hours behind GMT/UTC;

	from 1964-01-01 on, it again follows the "Brazil" rules.

I mentioned the way to interpret the "Brazil" rules in a previous email.

Also read Robert Elz's more detailed explanation.

> I see the note acknowledging Daylight Savings was scrapped, but not sure how you are getting that value correctly.

From that last line *and* from the "Brazil" rules.
 
> We are using a JODA library, and my understanding is it finds the timezone under the ?Zone? section, such as America/Sao_Paulo, and finds the bottom most value for the most current timezone.

Presumably Joda-Time can process dates and times other than "right now", which means that it does *not* necessarily find the bottommost value, because that value might not be the one that applies - if it's 1963-11-27, for example, the *previous* line:

                                  -3:00      1:00       -02       1964
applies.

If a line that has a name, rather than a number, in the second field applies, it would also have to look at the "Rules" section and find the appropriate one of the "Brazil" entries there.

(Or maybe it does processing similar to zic, reading the entire file and building a table of transition timestamps and UTC offsets - or just reads compiled zic files.)

> For America/Sao_Paulo it says:
> -3:00      Brazil     -03/-02
>  
> Are we not looking in the correct place?  In the ?Rule? section I don?t see anything that would give me -3:00 without DST.

See my earlier email about the "Rules" section.

From stefan.rueger at theblueorange.space  Sat Dec  7 17:21:05 2019
From: stefan.rueger at theblueorange.space (Stefan Rueger)
Date: Sat, 7 Dec 2019 17:21:05 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
Message-ID: <20191207172105.GA18617@cedar>

Looks like zdump claims Dublin has DST during winter, not summer:

$ ./zdump -i -c2020,2021 Europe/Dublin

TZ="Europe/Dublin"
-	-	+00	GMT	1
2020-03-29	02	+01	IST
2020-10-25	01	+00	GMT	1

Compare with the output for London, which is as I would expect:

$ ./zdump -i -c2020,2021 Europe/London

TZ="Europe/London"
-	-	+00	GMT
2020-03-29	02	+01	BST	1
2020-10-25	01	+00	GMT

Generally, I think it's neater if the time stretches with the larger GMT values are considered DST. This is almost always true, except for Europe/Dublin, Eire, Africa/Casablanca and Africa/El_Aaiun.

Morocco (and Western Sahara) change the time to have shorter fasts during Ramadan, so to speak to *not* save daylight. I would therefore still argue that the time outside Ramadan should be considered DST and the time during Ramadan the non-DST time.

I am aware that the view "DST means larger GMT value" is not a precise definition (a region that change times zones in quick succession might easily accrue more than two GMT values within a few years). It's therefore not a great candidate for implementation in zic/zdump. However, I hold that periodic *future* annual back-and-forth switches should adopt that principle.

Anyway, over to you


Stefan

PS: You are providing an *amazing* service - many thanks for that!

From eggert at cs.ucla.edu  Tue Dec 10 23:02:33 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Tue, 10 Dec 2019 15:02:33 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191207172105.GA18617@cedar>
References: <20191207172105.GA18617@cedar>
Message-ID: <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>

On 12/7/19 9:21 AM, Stefan Rueger wrote:
> I think it's neater if the time stretches with the larger GMT values are considered DST.

It is a controversial area because there are two competing objectives: 
having standard time be the standard UT offset ('std' in POSIX) vs 
having DST's offset be greater than standard time's. As noted in the 
'europe' file, in a comment from Joseph S. Myers (2005-01-26):

"(Note that the time in the Republic of Ireland since 1968 has been 
defined in terms of standard time being GMT+1 with a period of winter 
time when it is GMT, rather than standard time being GMT with a period 
of summer time being GMT+1.)"

and we eventually went with that interpretation, as opposed to the one 
you suggested.

Morocco is similar, as are some other historic uses of "winter time" as 
DST. (Whether this practice "saves" daylight depends on whether one 
prefers morning to evening daylight. :-)

If you prefer the other interpretation, you can get it with 'make 
rearguard_tarballs'.

From guy at alum.mit.edu  Tue Dec 10 23:43:19 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Tue, 10 Dec 2019 15:43:19 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
Message-ID: <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>

On Dec 10, 2019, at 3:02 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/7/19 9:21 AM, Stefan Rueger wrote:
>> I think it's neater if the time stretches with the larger GMT values are considered DST.
> 
> It is a controversial area because there are two competing objectives: having standard time be the standard UT offset ('std' in POSIX) vs having DST's offset be greater than standard time's. As noted in the 'europe' file, in a comment from Joseph S. Myers (2005-01-26):
> 
> "(Note that the time in the Republic of Ireland since 1968 has been defined in terms of standard time being GMT+1 with a period of winter time when it is GMT, rather than standard time being GMT with a period of summer time being GMT+1.)"
> 
> and we eventually went with that interpretation, as opposed to the one you suggested.

I.e., it *is* DST, except that the "S" stands for "spending" rather than "saving". :-)

Either that, or "S" stands for "shifting", in both the case of shifting the clock forward from standard time in the spring and the case of shifting the clock *backward* from standard time in the autumn.  (That also has the advantage of not claiming anything's "saved".)

C18 says that

	Some functions deal with local time, which is the calendar time expressed for some specific time zone, and with Daylight Saving Time, which is a temporary change in the algorithm for determining local time. The local time zone and Daylight Saving Time are implementation-defined.

and that

	The value of tm_isdst is positive if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and negative if the information is not available.

which leaves the interpretation to the implementation, as it doesn't say whether the time when the temporary change is *not* in effect must be the legally-defined "standard time" or not, nor whether the "temporary change" must set the clock forward.

POSIX appears not to disallow a TZ setting in which the "dst" offset is less than the "std" offset, unless I'm missing something, so, again, I'm not sure any standard forbids setting the clock *backwards* for "Daylight Saving Time".

From eggert at cs.ucla.edu  Wed Dec 11 18:09:45 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Wed, 11 Dec 2019 10:09:45 -0800
Subject: [tz] Iceland may move from +00 to -01
Message-ID: <392e16c9-8010-e139-b41d-bfca41d64d9a@cs.ucla.edu>

Since 1968 Reykjav?k has been about 1.5 hours ahead of mean solar time. 
The government of Iceland recently asked people which of three things 
they wanted to do about this, and the survey results were:

   4% - educational campaign to encourage people to go to bed earlier
  37% - leave the clocks alone
  56% - change from +00 to -01

The prime minister's office is drafting a bill to implement the majority 
opinion: this would undo the 1968 change from -01/+00 (with DST) to 
permanent +00, and would revert to permanent -01, which was observed 
1908-1916 and 1922-1938.

Although I've seen many proposals from around the world to change the 
clocks, this bill seems to have a real chance of passing so I thought 
I'd give the list a heads-up.

My source:

Fontaine A. Most Icelanders support changing Iceland?s time zone. 
Reykjav?k Grapevine. 2019-12-11. 
https://grapevine.is/news/2019/12/11/most-icelanders-support-changing-icelands-time-zone/

From michael.h.deckers at googlemail.com  Wed Dec 11 18:12:25 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Wed, 11 Dec 2019 18:12:25 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
Message-ID: <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>


 ?? On 2019-12-10 23:43, Guy Harris wrote:

> POSIX appears not to disallow a TZ setting in which the "dst" offset is less than the "std" offset, unless I'm missing something, so, again, I'm not sure any standard forbids setting the clock *backwards* for "Daylight Saving Time".


 ?? I see this more as a problem of upward compatibility of tzdb, not
 ?? of POSIX: for more than twenty years, the tzdb description in
 ?? newctime.3 has guaranteed (in addition to what C and POSIX require)
 ?? that
 ????? "Tm_isdst is non-zero if summer time is in effect"
 ?? and probably the "if" was even meant as "if and only if".

 ?? This is no longer true since 2018c, but the interface description
 ?? in newctime.3 was changed only in 2018f (without advert in NEWS). Some
 ?? programs had relied on the old interface description, and have since
 ?? adapted their functionality.

 ?? For others, I do not know. For instance, the PHP date_format() 
function has
 ?? a format specifier "I" for an indication of winter and summer time. 
Has the
 ?? semantics of that format specifier changed? Or has it been removed?

 ?? Due to the importance of tzdb, and its widespread use, even tiny changes
 ?? in its external interfaces may cause compatibility problems. Using
 ?? "rearguard" tzdb data can help in transitions.

 ?? Michael Deckers.


From eggert at cs.ucla.edu  Wed Dec 11 18:39:07 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Wed, 11 Dec 2019 10:39:07 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
Message-ID: <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>

On 12/11/19 10:12 AM, Michael H Deckers wrote:
>     the tzdb description in
>  ?? newctime.3 ... guaranteed (in addition to what C and POSIX require)
>  ?? that
>  ????? "Tm_isdst is non-zero if summer time is in effect"
>  ?? and probably the "if" was even meant as "if and only if".

I don't think that old wording was ever intended to mean that tm_isdst 
was to be set only in summer, or even only in daylight-saving periods 
that were used in summer and adjacent time periods. Such a meaning would 
have been contradicted by longstanding data, such as Belize's observance 
of DST from October through February in late 1918 through early 1943.

Instead, it was merely sloppy wording where "summer time" was 
incorrectly used as a synonym for "daylight saving time", the wording 
that is in the relevant standards and that corresponds to the 
abbreviation "tm_isdst".

From michael.h.deckers at googlemail.com  Wed Dec 11 21:39:00 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Wed, 11 Dec 2019 21:39:00 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
Message-ID: <402c5bee-6e5f-0c8a-c0e1-d082c986f33d@googlemail.com>


 ?? On 2019-12-11 18:39, Paul Eggert wrote:

> Instead, it was merely sloppy wording where "summer time" was 
> incorrectly used as a synonym for "daylight saving time", the wording 
> that is in the relevant standards and that corresponds to the 
> abbreviation "tm_isdst".


 ?? You are right, "summer time" would be a "sloppy wording"
 ?? for winter time in Ireland.

 ?? Michael Deckers.


From marc.sackeli at gmail.com  Wed Dec 11 23:14:10 2019
From: marc.sackeli at gmail.com (Marc Sackeli)
Date: Wed, 11 Dec 2019 15:14:10 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
Message-ID: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>

I apologize if this is a repeat question, but this question pertains
specifically to how the tz database might change if individual US states
start adhering to their own DST rules.

There has been a wave of legislation
<https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#2015%E2%80%932019_Proposals_for_the_introduction_of_Year-Round_DST>
coming
from individual states trying to shift towards a year-round DST model.
While several states have successfully passed this legislation, their
ability to shift is reliant on federal approval. Arizona has been able to
drum to their own beat on DST, and I don't think it's far fetched to think
other states might be allowed to do so in the future as well.

If this is a potential outcome, is there an idea of how the tz database
would adapt to this change? My guess is that new entries would be created
to allow us to delineate between these states. We are currently covered if
California decides to change thanks to America/Los_Angeles, but what if
Oregon or Tennessee decides they want to change? Does this mean
America/Portland and America/Nashville would be created? Or perhaps
America/Oregon and America/Tennessee?

Any thoughts would be appreciated.

-Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191211/1ebd9f8d/attachment.html>

From eggert at cs.ucla.edu  Wed Dec 11 23:20:09 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Wed, 11 Dec 2019 15:20:09 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
Message-ID: <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>

On 12/11/19 3:14 PM, Marc Sackeli wrote:
> If this is a potential outcome, is there an idea of how the tz database 
> would adapt to this change? My guess is that new entries would be 
> created to allow us to delineate between these states.

Right.

> We are currently 
> covered if California decides to change thanks to America/Los_Angeles,

Not if the rest of the Pacific time zone decides not to change. In that 
case, we'd need to create America/Seattle etc. We'd prefer city names to 
state names, as that's the convention.

From guy at alum.mit.edu  Wed Dec 11 23:21:15 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Wed, 11 Dec 2019 15:21:15 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
Message-ID: <F176D8D8-EA73-4240-AF5F-4BBFA36DEC22@alum.mit.edu>

On Dec 11, 2019, at 3:14 PM, Marc Sackeli <marc.sackeli at gmail.com> wrote:

> If this is a potential outcome, is there an idea of how the tz database would adapt to this change? My guess is that new entries would be created to allow us to delineate between these states.

Yes.

> We are currently covered if California decides to change thanks to America/Los_Angeles, but what if Oregon or Tennessee decides they want to change? Does this mean America/Portland and America/Nashville would be created?

Yes.

> Or perhaps America/Oregon and America/Tennessee?

No.

	ftp://ftp.iana.org/tz/tzdb-2018g/theory.html

"Names of timezones

Each timezone has a unique name. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like "Ruthenia" instead of the timezone name "Europe/Uzhgorod". If geolocation information is available, a selection interface can locate the user on a timezone map or prioritize names that are geographically close. For an example selection interface, see the tzselect program in the tz code. The Unicode Common Locale Data Repository contains data that may be useful for other selection interfaces; it maps timezone names like Europe/Uzhgorod to CLDR names like uauzh which are in turn mapped to locale-dependent strings like "Uzhhorod", "Ungv?r", "???????", and "?????".

The naming conventions attempt to strike a balance among the following goals:

	? Uniquely identify every timezone where clocks have agreed since 1970. This is essential for the intended use: static clocks keeping local civil time.
	? Indicate to experts where the timezone's clocks typically are.
	? Be robust in the presence of political changes. For example, names of countries are ordinarily not used, to avoid incompatibilities when countries change their name (e.g., Zaire?Congo) or when locations change countries (e.g., Hong Kong from UK colony to China).
	? Be portable to a wide variety of implementations.
	? Use a consistent naming conventions over the entire world.
Names normally have the form AREA/LOCATION, where AREA is a continent or ocean, and LOCATION is a specific location within the area. North and South America share the same area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York', and 'Pacific/Honolulu'. Some names are further qualified to help avoid confusion; for example, 'America/Indiana/Petersburg' distinguishes Petersburg, Indiana from other Petersburgs in America.

Here are the general guidelines used for choosing timezone names, in decreasing order of importance:

	? Use only valid POSIX file name components (i.e., the parts of names other than '/'). Do not use the file name components '.' and '..'. Within a file name component, use only ASCIIletters, '.', '-' and '_'. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with '-'. E.g., prefer Asia/Brunei to Asia/Bandar_Seri_Begawan. Exceptions: see the discussion of legacy names below.
	? A name must not be empty, or contain '//', or start or end with '/'.
	? Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case.
	? If one name A is an initial prefix of another name AB (ignoring case), then B must not start with '/', as a regular file cannot have the same name as a directory in POSIX. For example, America/New_York precludes America/New_York/Bronx.
	? Uninhabited regions like the North Pole and Bouvet Island do not need locations, since local time is not defined there.
	? There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory.
	? If all the clocks in a timezone have agreed since 1970, do not bother to include more than one timezone even if some of the clocks disagreed before 1970. Otherwise these tables would become annoyingly large.
	? If a name is ambiguous, use a less ambiguous alternative; e.g., many cities are named San Jos? and Georgetown, so prefer America/Costa_Rica to America/San_Jose and America/Guyana to America/Georgetown.
	? Keep locations compact. Use cities or small islands, not countries or regions, so that any future changes do not split individual locations into different timezones. E.g., prefer Europe/Paris to Europe/France, since France has had multiple time zones.
	? Use mainstream English spelling, e.g., prefer Europe/Rome to Europa/Roma, and prefer Europe/Athens to the Greek ??????/????? or the Romanized Evr?pi/Ath?na. The POSIX file name restrictions encourage this guideline.
	? Use the most populous among locations in a region, e.g., prefer Asia/Shanghai to Asia/Beijing. Among locations with similar populations, pick the best-known location, e.g., prefer Europe/Rome to Europe/Milan.
	? Use the singular form, e.g., prefer Atlantic/Canary to Atlantic/Canaries.
	? Omit common suffixes like '_Islands' and '_City', unless that would lead to ambiguity. E.g., prefer America/Cayman to America/Cayman_Islands and America/Guatemala toAmerica/Guatemala_City, but prefer America/Mexico_City to America/Mexico because the country of Mexico has several time zones.
	? Use '_' to represent a space.
	? Omit '.' from abbreviations in names. E.g., prefer Atlantic/St_Helena to Atlantic/St._Helena.
	? Do not change established names if they only marginally violate the above guidelines. For example, do not change the existing name Europe/Rome to Europe/Milan merely because Milan's population has grown to be somewhat greater than Rome's.
	? If a name is changed, put its old spelling in the 'backward' file. This means old spellings will continue to work."

In particular, note

	Keep locations compact. Use cities or small islands, not countries or regions, so that any future changes do not split individual locations into different timezones. E.g., prefer Europe/Paris to Europe/France, since France has had multiple time zones.

From marc.sackeli at gmail.com  Wed Dec 11 23:30:38 2019
From: marc.sackeli at gmail.com (Marc Sackeli)
Date: Wed, 11 Dec 2019 15:30:38 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
 <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
Message-ID: <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>

Understood.  From the looks of it, state names are only used when the state
itself doesn't adhere to a single timezone. North Dakota, Kentucky,
Indiana, etc.

Thanks for the response, that's clear things up for me.



On Wed, Dec 11, 2019 at 3:20 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/11/19 3:14 PM, Marc Sackeli wrote:
> > If this is a potential outcome, is there an idea of how the tz database
> > would adapt to this change? My guess is that new entries would be
> > created to allow us to delineate between these states.
>
> Right.
>
> > We are currently
> > covered if California decides to change thanks to America/Los_Angeles,
>
> Not if the rest of the Pacific time zone decides not to change. In that
> case, we'd need to create America/Seattle etc. We'd prefer city names to
> state names, as that's the convention.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191211/f0343959/attachment.html>

From eggert at cs.ucla.edu  Wed Dec 11 23:37:31 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Wed, 11 Dec 2019 15:37:31 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
 <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
 <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>
Message-ID: <deeeb23e-3d4a-7e54-72d6-cc81f0f8bc94@cs.ucla.edu>

On 12/11/19 3:30 PM, Marc Sackeli wrote:
>  From the looks of it, state names are only used when the state itself 
> doesn't adhere to a single timezone.

Yes, but that's for directory names, e.g., America/Indiana/Petersburg; 
there is no America/Indiana zone. This is more to handle 
ambiguity/obscurity.

We will be in trouble if the state of New York splits, since 
America/New_York cannot be a directory name.

From marc.sackeli at gmail.com  Thu Dec 12 00:49:44 2019
From: marc.sackeli at gmail.com (Marc Sackeli)
Date: Wed, 11 Dec 2019 16:49:44 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <deeeb23e-3d4a-7e54-72d6-cc81f0f8bc94@cs.ucla.edu>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
 <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
 <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>
 <deeeb23e-3d4a-7e54-72d6-cc81f0f8bc94@cs.ucla.edu>
Message-ID: <CAPEb5JJad49K6HZMUXymiKbqM6aCdV=J1LXFDcef+-cOS0seGA@mail.gmail.com>

Guy, Paul,

Thanks for the follow ups. I've read the doc that Guy sent over and it
helped put things into context, especially the directory usage.

On 12/11/19 3:37 PM, Paul Eggert wrote:
> We will be in trouble if the state of New York splits,
> since America/New_York cannot be a directory name.
That is a tricky scenario. Thankfully that type of naming overlap seems
like an outlier. I'd like to think we are OK there given New York's
position within EST.

On a side note, how are you both extracting and formatting my quotes so
nicely in your replies? I manually made mine to match your format.

Best,
Marc

On Wed, Dec 11, 2019 at 3:37 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/11/19 3:30 PM, Marc Sackeli wrote:
> >  From the looks of it, state names are only used when the state itself
> > doesn't adhere to a single timezone.
>
> Yes, but that's for directory names, e.g., America/Indiana/Petersburg;
> there is no America/Indiana zone. This is more to handle
> ambiguity/obscurity.
>
> We will be in trouble if the state of New York splits, since
> America/New_York cannot be a directory name.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191211/d6cdf43b/attachment.html>

From Brian.Inglis at SystematicSw.ab.ca  Thu Dec 12 16:29:03 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Thu, 12 Dec 2019 09:29:03 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
Message-ID: <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>

On 2019-12-11 11:39, Paul Eggert wrote:
> On 12/11/19 10:12 AM, Michael H Deckers wrote:
>> ??? the tzdb description in
>> ??? newctime.3 ... guaranteed (in addition to what C and POSIX require)
>> ??? that
>> ?????? "Tm_isdst is non-zero if summer time is in effect"
>> ??? and probably the "if" was even meant as "if and only if".
> 
> I don't think that old wording was ever intended to mean that tm_isdst was to be
> set only in summer, or even only in daylight-saving periods that were used in
> summer and adjacent time periods. Such a meaning would have been contradicted by
> longstanding data, such as Belize's observance of DST from October through
> February in late 1918 through early 1943.
> 
> Instead, it was merely sloppy wording where "summer time" was incorrectly used
> as a synonym for "daylight saving time", the wording that is in the relevant
> standards and that corresponds to the abbreviation "tm_isdst".

It is more likely that the term was correctly used in some other locale, where
summer (and winter) time is often the legal wording in various languages, where
the equivalents of "daylight saving" and "standard", used in North America, are
not used or don't exist; sometimes the equivalents of "civil time" and "advanced
time" are used instead, but nothing helps when standard is advanced relative to
the alternative.

I preferred whichever reference used the terms "standard time" and "alternative
time", as that seems to be a more accurate wording for current (existing) usage.
Of course, summer and winter time are also useful and accurate, but the offset
relative values may not be as expected.

Perhaps tm_isdst should always be set to -1 for inverted zones, where it does
not represent summer or saving time, or even set it for all zones permanently to
-1?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

From Brian.Inglis at SystematicSw.ab.ca  Thu Dec 12 17:20:26 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Thu, 12 Dec 2019 10:20:26 -0700
Subject: [tz] EU and Brexit Time Borders
Message-ID: <9e73addd-8b92-93c6-c89d-cf143a9aab8a@SystematicSw.ab.ca>

EU member states get to decide whether to stay on summer or standard time:

https://www.independent.ie/business/brexit/meps-vote-to-end-daylight-savings-which-may-result-in-two-irish-time-zones-37955161.html

What will Ireland do, and will Ulster follow Irish or UK time?

https://www.independent.co.uk/news/uk/politics/brexit-irish-border-time-clock-change-daylight-savings-boris-johnson-a9169326.html

Will UK follow, staying on GMT or BST, or keep switching?

https://www.rospa.com/media/documents/road-safety/consultation-responses/discontinuing-seasonal-changes-of-time.pdf

"Under the new legislation, governments opting to make summer-time permanent
would adjust their clocks for the last time on the last Sunday in March 2021.
For those choosing permanent standard time, known as permanent winter-time, the
final clock change would be on the last Sunday of October 2021."

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

From eggert at cs.ucla.edu  Thu Dec 12 20:59:34 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Thu, 12 Dec 2019 12:59:34 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <DM6PR04MB428329B7C1C67F1558E2B486A2550@DM6PR04MB4283.namprd04.prod.outlook.com>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
 <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
 <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>
 <deeeb23e-3d4a-7e54-72d6-cc81f0f8bc94@cs.ucla.edu>
 <DM6PR04MB428329B7C1C67F1558E2B486A2550@DM6PR04MB4283.namprd04.prod.outlook.com>
Message-ID: <1476e19b-03b5-0171-a111-4d05e6b8ecae@cs.ucla.edu>

On 12/12/19 7:39 AM, David Braverman wrote:
> Can we use America/New_York_State/Buffalo, for example?

That would work, yes. But let's hope Buffalo stays aligned.

From kre at munnari.OZ.AU  Fri Dec 13 00:17:16 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Fri, 13 Dec 2019 07:17:16 +0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>
References: <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
Message-ID: <13633.1576196236@jinx.noi.kre.to>

    Date:        Thu, 12 Dec 2019 09:29:03 -0700
    From:        Brian Inglis <Brian.Inglis at SystematicSw.ab.ca>
    Message-ID:  <4e191681-6342-a5d3-e539-945a50fd11c3 at SystematicSw.ab.ca>

  | I preferred whichever reference used the terms "standard time"
  | and "alternative time",

That was POSIX, before it was changed (not yet published, but applied,
"alternative time" will no longer appear when the next edition is pubished)
based upon some input from this direction.

But, while I agree it was better, it's not good enough either - first
because there's not just two, and second, because there's no point giving
these things a name - whatever time it is (commonly agreed, whether
legislatively backed or not) is "standard time" - that's what it means
to be "standard".   The only other thing we can (at least currently) rely
upon is that there is a current offset from UTC (ie: that UTC is stable,
and the time anywhere is, for a short while anyway, a constant offset
from UTC - positive or negative (or 0)).

Some juristictions provide names for the various times, mostly for convenience
around the transitions, but none of them are very useful, and here we really
cannot rely upon any such thing existing.

tm_isdst was originally just intended as an index into tzname[] to get
the (assumed always to exist) "name" of the current time (nb: not timezone).
Both of the assumptions there are demonstrably false, first that there is
a name to get, and second that there are just two (0 or 1 in tm_isdst).
tzname[] is also an interface disaster, and should be retired, and if it
is, the sole rational reason for tm_isdst to exist at all will vanish, and
it can be deleted as well.

[The addition of -1 as a tm_isdst value "don't know" when it is used as
input to mktime() came later - as did mktime - that was a hack, still is].

But please people, we have had this discussion over and over, nothing is
going to change anytime in the forseeable future, neither to correct any
"bugs" that appear to exist (they don't - or not in this area) nor to
actually make the interface more sane.

There's no point continually discussing it.

kre


From olopierpa at gmail.com  Fri Dec 13 02:54:00 2019
From: olopierpa at gmail.com (Pierpaolo Bernardi)
Date: Fri, 13 Dec 2019 03:54:00 +0100
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <13633.1576196236@jinx.noi.kre.to>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
 <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>
 <13633.1576196236@jinx.noi.kre.to>
Message-ID: <CANY8u7F+z6-oH1N_GpEDye-yJt33Q1-6HofV1bXUk=LTydmp4A@mail.gmail.com>

On Fri, Dec 13, 2019 at 1:17 AM Robert Elz <kre at munnari.oz.au> wrote:

> But please people, we have had this discussion over and over, nothing is
> going to change anytime in the forseeable future, neither to correct any
> "bugs" that appear to exist (they don't - or not in this area) nor to
> actually make the interface more sane.

There's no chance to change the existing posix calls. But there's a
possibility to add a completely new set of calls which could
eventually supersede the current set as the recommended way to handle
time.

From kre at munnari.OZ.AU  Fri Dec 13 04:01:47 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Fri, 13 Dec 2019 11:01:47 +0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <CANY8u7F+z6-oH1N_GpEDye-yJt33Q1-6HofV1bXUk=LTydmp4A@mail.gmail.com>
References: <CANY8u7F+z6-oH1N_GpEDye-yJt33Q1-6HofV1bXUk=LTydmp4A@mail.gmail.com>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
 <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>
 <13633.1576196236@jinx.noi.kre.to>
Message-ID: <2485.1576209707@jinx.noi.kre.to>

    Date:        Fri, 13 Dec 2019 03:54:00 +0100
    From:        Pierpaolo Bernardi <olopierpa at gmail.com>
    Message-ID:  <CANY8u7F+z6-oH1N_GpEDye-yJt33Q1-6HofV1bXUk=LTydmp4A at mail.gmail.com>

  | There's no chance to change the existing posix calls. But there's a
  | possibility to add a completely new set of calls which could

Yes, agreed.   That would be the way forward.

kre


From stefan.rueger at theblueorange.space  Wed Dec 11 19:23:27 2019
From: stefan.rueger at theblueorange.space (Stefan Rueger)
Date: Wed, 11 Dec 2019 19:23:27 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
Message-ID: <20191211192327.GA18736@cedar>

On Tue, Dec 10, 2019 at 23:43, Guy Harris wrote:
| I.e., it *is* DST, except that the "S" stands for "spending" rather than "saving". :-)

:-) It's mostly a matter of documentation and expectation. I for one have been surprised by the recent change of interpretation to the extent that I thought this is a bug - despite having read the documentation to a reasonable depth in 2017. I've changed my programme to no longer use isdst (or rely on what I thought isdst meant).

Can I suggest to make explicit in zdump's manpage (and other places) that isdst==1 doesn't necessarily mean clocks going forward. I believe that daylight saving time is widely understood to be synonymous with summer time: https://en.wikipedia.org/wiki/Daylight_saving_time Again, a simple case of noting in the documentation that this is not the intended interpretation here.

Cheers


Stefan

I feel there were missed opportunities, too, when developing standards: Rather than foregrounding time difference to GMT and isdst (1 for DXT "daylight changed time", 0 for normal and -1 for unknown) one might have foregrounded the difference to what the region considers its normal time zone and the current offset owing to DXT, if any. Using the current interpretation the DXT offset would be -1 for Ireland and 1 for the UK (while Antarctica/Troll would be 2 and Lord Howe Island 0.5). That way the difference to GMT would be the sum of slow changing (geographic timezone) and potentially annually changing (DXT) offsets. In my mind this would have been more informative and easier to understand than isdst.


From clive at davros.org  Fri Dec 13 22:13:36 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Fri, 13 Dec 2019 22:13:36 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191211192327.GA18736@cedar>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar>
Message-ID: <20191213221336.GE24121@davros.org>

Stefan Rueger said:
> I feel there were missed opportunities, too, when developing standards: Rather than foregrounding time difference to GMT and isdst (1 for DXT "daylight changed time", 0 for normal and -1 for unknown) one might have foregrounded the difference to what the region considers its normal time zone and the current offset owing to DXT, if any. Using the current interpretation the DXT offset would be -1 for Ireland and 1 for the UK (while Antarctica/Troll would be 2 and Lord Howe Island 0.5). That way the difference to GMT would be the sum of slow changing (geographic timezone) and potentially annually changing (DXT) offsets. In my mind this would have been more informative and easier to understand than isdst.

I don't disagree with you. The problem is that the original standards were
mostly written by US people who assume that the whole world works their way.
Where there's a clean sheet to start from, we can do better things [1], but
that's a lot harder with a large installed base.

The US-centric problem isn't new to this. I've lost count how many web
sites can't cope with the fact that I don't have a zip code or that I have
two middle initials, not one. I'm lucky that I don't have any non-ASCII
characters in my name; there's a whole nother minefield waiting there.

Allow me to point you at:
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
https://wiesmann.codiferes.net/wordpress/?p=15187&lang=en

[1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
internally for all timestamps, leaving the leap second mess to the
periphery.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

From Brian.Inglis at SystematicSw.ab.ca  Sat Dec 14 06:20:39 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Fri, 13 Dec 2019 23:20:39 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191213221336.GE24121@davros.org>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
Message-ID: <c432c71d-0d97-767d-7726-3c62d5598047@SystematicSw.ab.ca>

On 2019-12-13 15:13, Clive D.W. Feather wrote:
> I don't disagree with you. The problem is that the original standards were
> mostly written by US people who assume that the whole world works their way.
> Where there's a clean sheet to start from, we can do better things [1], but
> that's a lot harder with a large installed base.

Is anyone aware of any plans to backport C++ work on chrono, date, tz, calendar,
etc. APIs to POSIX and/or C?

> The US-centric problem isn't new to this. I've lost count how many web
> sites can't cope with the fact that I don't have a zip code or that I have
> two middle initials, not one. I'm lucky that I don't have any non-ASCII
> characters in my name; there's a whole nother minefield waiting there.
>  
> Allow me to point you at:
> https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
> https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
> https://wiesmann.codiferes.net/wordpress/?p=15187&lang=en

Comprehensive list of lists:
	https://github.com/kdeldycke/awesome-falsehood

> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
> internally for all timestamps, leaving the leap second mess to the
> periphery.

How does TAI get set given that mostly UTC is distributed and LS need to be
added to get TAI? Or do you mean an arbitrary TAI timescale ignoring LS?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

From guy at alum.mit.edu  Sat Dec 14 09:09:38 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sat, 14 Dec 2019 01:09:38 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191213221336.GE24121@davros.org>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
Message-ID: <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>

On Dec 13, 2019, at 2:13 PM, Clive D.W. Feather <clive at davros.org> wrote:

> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
> internally for all timestamps, leaving the leap second mess to the
> periphery.

Yes, section 5.1.1 "Time" of

	https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634

specifies that the base representation of times is the number of seconds that have elapsed since 1999-12-31T23:59:28 UTC. :-) :-) :-) :-) :-)

(I.e., the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as an instant of time that has more zeroes in the way it's represented as TAI than in the way it's represented as UTC.  If it had been defined as the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC. that would still "leave the leap second mess to the periphery"; it would just mean that the count of seconds would be 32 seconds lower.

By the way, how is TAI, represented as YYYY-MM-DDTHH:MM:SS TAI, defined?  Does it have a Gregorian-style calendar made up entirely of 86400-second days, so that most years are exactly 31,536,000 seconds long, with some years being exactly 31,622,400 seconds long?  If so, then there are at least four different flavors of time stamp, with "time stamp" defined as "label assigned to an instant of time":

	1) "TAI-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, with non-leap years being exactly 31,536,000 seconds long and leap years being exactly 31,622,400 seconds long, so that SS goes from 00 to 59, never to 60;

	2) "UTC-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, but with some years being 31,536,001 seconds, 31,622,401 seconds long, or 31,622,402 seconds long, depending on how many leap seconds there were during the year, so SS could occasionally go from 59 to 60;

	3) counts of seconds since a specified epoch, with the count including leap seconds;

	4) counts of non-leap seconds since a specified epoch.

Note that 3) could use either a TAI-style calendar+clock or a UTC-style calendar+lock to specify the epoch; the same is true of 4).)

From clive at davros.org  Sat Dec 14 09:18:19 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Sat, 14 Dec 2019 09:18:19 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <c432c71d-0d97-767d-7726-3c62d5598047@SystematicSw.ab.ca>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <c432c71d-0d97-767d-7726-3c62d5598047@SystematicSw.ab.ca>
Message-ID: <20191214091819.GA30165@davros.org>

Brian Inglis said:
>> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
>> internally for all timestamps, leaving the leap second mess to the
>> periphery.
> 
> How does TAI get set given that mostly UTC is distributed and LS need to be
> added to get TAI? Or do you mean an arbitrary TAI timescale ignoring LS?

No, that's what I meant by "the periphery".

The management device - perhaps your phone or in a big site one of the
servers - has to know all about time zones and leap seconds. But if you
want 87 lights to turn on at exactly 06:23:45 tomorrow, you don't need
those 87 light bulbs to all have to manage time zone and leap second
tables [1]. The main network just sends out times as TAI/UTC seconds since
an epoch.

[1] This isn't a joke. A major use case for Mesh is controlling lights in a
large building without lots of cables to light switches: the switches can
be little battery-powered things that sit on a desk or are stuck to the
wall.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

From clive at davros.org  Sat Dec 14 09:23:22 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Sat, 14 Dec 2019 09:23:22 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
Message-ID: <20191214092322.GB30165@davros.org>

Guy Harris said:
>> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
>> internally for all timestamps, leaving the leap second mess to the
>> periphery.
> 
> Yes, section 5.1.1 "Time" of
> 
> 	https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634
> 
> specifies that the base representation of times is the number of seconds that have elapsed since 1999-12-31T23:59:28 UTC. :-) :-) :-) :-) :-)

Yes. But ...

> (I.e., the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as an instant of time that has more zeroes in the way it's represented as TAI than in the way it's represented as UTC.  If it had been defined as the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC. that would still "leave the leap second mess to the periphery"; it would just mean that the count of seconds would be 32 seconds lower.

No, that's not the only way.

> By the way, how is TAI, represented as YYYY-MM-DDTHH:MM:SS TAI, defined?  Does it have a Gregorian-style calendar made up entirely of 86400-second days, so that most years are exactly 31,536,000 seconds long, with some years being exactly 31,622,400 seconds long?

Yes, and that's a big part of "avoiding the mess" - you don't worry about
time zones *or* leap seconds.

> If so, then there are at least four different flavors of time stamp, with "time stamp" defined as "label assigned to an instant of time":
> 
> 	1) "TAI-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, with non-leap years being exactly 31,536,000 seconds long and leap years being exactly 31,622,400 seconds long, so that SS goes from 00 to 59, never to 60;

That's what Mesh uses when handling a "broken-down" time. Hence "TAI".

> 	3) counts of seconds since a specified epoch, with the count including leap seconds;

And that's what Mesh uses when just counting seconds. I agree that it
doesn't matter whether you could TAI seconds or UTC seconds, because
they're exactly the same.

> Note that 3) could use either a TAI-style calendar+clock or a UTC-style calendar+lock to specify the epoch; the same is true of 4).)

True. But that excludes your item 1.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

From guy at alum.mit.edu  Sat Dec 14 09:57:38 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sat, 14 Dec 2019 01:57:38 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191214092322.GB30165@davros.org>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
Message-ID: <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>

On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:

> Guy Harris said:
>>> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
>>> internally for all timestamps, leaving the leap second mess to the
>>> periphery.
>> 
>> Yes, section 5.1.1 "Time" of
>> 
>> 	https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634
>> 
>> specifies that the base representation of times is the number of seconds that have elapsed since 1999-12-31T23:59:28 UTC. :-) :-) :-) :-) :-)
> 
> Yes. But ...
> 
>> (I.e., the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as an instant of time that has more zeroes in the way it's represented as TAI than in the way it's represented as UTC.  If it had been defined as the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC. that would still "leave the leap second mess to the periphery"; it would just mean that the count of seconds would be 32 seconds lower.
> 
> No, that's not the only way.

What's the other way?

>> By the way, how is TAI, represented as YYYY-MM-DDTHH:MM:SS TAI, defined?  Does it have a Gregorian-style calendar made up entirely of 86400-second days, so that most years are exactly 31,536,000 seconds long, with some years being exactly 31,622,400 seconds long?
> 
> Yes, and that's a big part of "avoiding the mess" - you don't worry about
> time zones *or* leap seconds.

...unless you need to convert a Bluetooth Mesh time stamp to UTC.

And the same would be true if it counted the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC.

>> If so, then there are at least four different flavors of time stamp, with "time stamp" defined as "label assigned to an instant of time":
>> 
>> 	1) "TAI-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, with non-leap years being exactly 31,536,000 seconds long and leap years being exactly 31,622,400 seconds long, so that SS goes from 00 to 59, never to 60;
> 
> That's what Mesh uses when handling a "broken-down" time. Hence "TAI".

Preview doesn't report the word "broken" anywhere in the spec.  The times discussed in 5.1.4.2 Schedule Register presumably are, when no wildcards are involved, local dates/times, with a time stamp being a Gregorian-style YY-MM-DDTHH:MM:SS, and with non-leap years being either 31,536,000, 31,536,001, or 31,536,002 seconds long, and with leap years being either 31,622,400, 31,622,401, or 31,622,402 seconds long (which might disagree with most real-world clocks, as those clocks probably behave as if you had a UTC calendar and a clock that ticks like TAI, in the sense that it always goes from 23:59:59 to 00:00:00, but that's some number of seconds off from TAI).

The Time state includes TAI-UTC Delta Current, TAI-UTC Delta New, and TAI of Delta Change; those require dealing with leap seconds.

>> 	3) counts of seconds since a specified epoch, with the count including leap seconds;
> 
> And that's what Mesh uses when just counting seconds. I agree that it
> doesn't matter whether you could TAI seconds or UTC seconds, because
> they're exactly the same.

I.e., nothing prevents such a clock from

>> Note that 3) could use either a TAI-style calendar+clock or a UTC-style calendar+lock to specify the epoch; the same is true of 4).)
> 
> True. But that excludes your item 1.

3) and 4) both completely exclude 1) and 2) - they're all different schemes for time-stamping instants of time, so 1) excludes 2), 3), and 4), 2) excludes 1), 3), and 4), 3) excludes 1), 2), and 4), and 4) excludes 1), 2) and 3).  For 1) and 2), a time stamp would look like 2019-12-15T09:54:56; for 3) and 4), a time stamp would look like 1576317243.

Both 3) and 4) could use either a 1)-style stamp or a 2)-style stamp in whatever spec defines the epoch.

(The point is that, in a time stamping mechanism that stamps times with counts of seconds since an epoch, whether the count includes leap seconds is independent of whether the specification for the epoch includes the letters "T", "A", and "I" in sequence with no spaces between them or includes the letters "U", "T", and "C" in sequence with no spaces between them.)

From scs at eskimo.com  Sat Dec 14 16:00:48 2019
From: scs at eskimo.com (Steve Summit)
Date: Sat, 14 Dec 2019 11:00:48 -0500
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
Message-ID: <2019Dec14.1100.scs.0003@quinine2.home>

Guy Harris wrote:
> On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:
>> Guy Harris said:
>>> ...the only way in which it "uses TAI" rather than using UTC is that
>>> the epoch is defined as...
>>
>> No, that's not the only way.
>
> What's the other way?

I'm guessing that the other way boils down to (however you try to
represent dates and times) *not* having any leap seconds anywhere
-- that is, unambiguously working in TAI everywhere, and drifting
farther away from UTC every time there's a leap second.

>> Yes, and that's a big part of "avoiding the mess" - you don't
>> worry about time zones *or* leap seconds.
>
> ...unless you need to convert a Bluetooth Mesh time stamp to UTC.

Right.  I imagine that's a pretty big problem.

> The times discussed in 5.1.4.2 Schedule Register presumably are [...]
> with non-leap years being either 31,536,000, 31,536,001, or 31,536,002
> seconds long

I wouldn't presume that at all.  If it's doing TAI, if it's not
counting leap seconds, why would you presume years of other than
31,536,000 or 31,622,400 seconds?

> The point is that, in a time stamping mechanism that stamps times with
> counts of seconds since an epoch, whether the count includes leap
> seconds is independent of whether the specification for the epoch
> includes the letters "T", "A", and "I" ...

There may be additional subtleties here that I'm overlooking,
but to me, this discussion cuts to the heart of the whole eternal
leap second imbroglio.

Guy has, I think, tried to carefully decouple two aspects of the
question:

A. Does your time scale count leap seconds or not, and
B. Does your representation use broken-down times ("calendar +
   clock"), or monotonic counts of seconds since an epoch?

I agree that those issues are orthogonal.  (I'm also going to
ignore for now the side question of whether the epoch mentioned
in "B" is defined as a UTC or TAI timestamp.)

So when Guy said "there are at least four different flavors of
time stamp", I think his flavors map onto my two aspects A and B
with this little truth table:

  A    B
 no   b-d   1) TAI-style calendar+clock
 yes  b-d   2) UTC-style calendar+clock
 no   mono  4) counts of non-leap seconds since a specified epoch
 yes  mono  3) counts of seconds since a specified epoch,
               with the count including leap seconds

Me, I would say that (1) and (4) are completely compatible --
they're two different representations for the same underlying
time scale.  You can perfectly interconvert between them using
the same algorithm Posix defines for time_t.

When it comes to UTC, however, (2) and (3) are most definitely
not compatible.  Personally, I believe that (2) is the *only*
way to represent UTC.  I believe -- Posix time_t most assuredly
notwithstanding -- that (3) is an abomination.

If you try to represent UTC using a monotonic count of seconds,
you have to either (a) ignore leap seconds after all (as Posix
does, but which totally contradicts those words "with the count
including leap seconds" in the definition of (3)), or (b) use
a kludgey and non-obvious (and non-Posix) mapping between your
monotonic time and broken-down calendar+time, a mapping which
always requires you to have a perfect leap second table available.

And in fact, if you try to do (b), I believe that you are *not*
really doing UTC, after all -- you are basically doing TAI
(perhaps with a slightly different epoch), and misleadingly
calling it UTC.  You are engendering just as much confusion as
the Posix time_t definition does.  A monotonic count of seconds
is simply not an appropriate representation for UTC.  The only
proper representation(s) of UTC are those that separate the date
from the time, so that they can cleanly, honestly, openly, and
explicitly accommodate those pesky days of other than 86400
seconds.

From guy at alum.mit.edu  Sat Dec 14 19:23:34 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sat, 14 Dec 2019 11:23:34 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <2019Dec14.1100.scs.0003@quinine2.home>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
Message-ID: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>

On Dec 14, 2019, at 8:00 AM, Steve Summit <scs at eskimo.com> wrote:

> Guy Harris wrote:
>> On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:
>>> Guy Harris said:
>>>> ...the only way in which it "uses TAI" rather than using UTC is that
>>>> the epoch is defined as...
>>> 
>>> No, that's not the only way.
>> 
>> What's the other way?
> 
> I'm guessing that the other way boils down to (however you try to
> represent dates and times) *not* having any leap seconds anywhere
> -- that is, unambiguously working in TAI everywhere, and drifting
> farther away from UTC every time there's a leap second.

Meaning, for example, that the time and date fields in 5.1.4.2 "Schedule Register" represent TAI times rather than local times?

The time stamps described in 5.1.1 "Time" are "type 3" in my list - a count of all elapsed seconds, including leap seconds, since a given epoch.

If you're keeping UTC - not the not-quite-UTC called "POSIX time" - you *also* need a count of all elapsed seconds, including leap seconds, since a given epoch, given that UTC time, like TAI time, changes even during positive leap seconds; it just happens to change in a different way.

In TAI, it always goes, presumably, from {day} 23:59:59 TAI to {next day} 00:00:00 TAI, regardless of whether a positive leap second is inserted at that instant of time or not.

In UTC, it goes from {day} 23:59:59 UTC to {same day} 23:59:60 UTC, and in the *next* second goes to {next day} 00:00:00 UTC.

It's only in times like "POSIX time" where it stays stuck at 23:59:59, or is slowed down, or whatever form of tweaking is done to pretend that every day is 86400 seconds long; that's not done in real UTC.

>>> Yes, and that's a big part of "avoiding the mess" - you don't
>>> worry about time zones *or* leap seconds.
>> 
>> ...unless you need to convert a Bluetooth Mesh time stamp to UTC.
> 
> Right.  I imagine that's a pretty big problem.
> 
>> The times discussed in 5.1.4.2 Schedule Register presumably are [...]
>> with non-leap years being either 31,536,000, 31,536,001, or 31,536,002
>> seconds long
> 
> I wouldn't presume that at all.  If it's doing TAI, if it's not
> counting leap seconds, why would you presume years of other than
> 31,536,000 or 31,622,400 seconds?

Because, in that section, it's *not* doing TAI:

	5.1.4.2 Schedule Register

	The Schedule Register state is a 16-entry, zero-based, indexed array of 76-bit values formatted as Scheduled Time. Each entry represents a state-changing event. *Time and date fields represent local time.*

> 
>> The point is that, in a time stamping mechanism that stamps times with
>> counts of seconds since an epoch, whether the count includes leap
>> seconds is independent of whether the specification for the epoch
>> includes the letters "T", "A", and "I" ...
> 
> There may be additional subtleties here that I'm overlooking,
> but to me, this discussion cuts to the heart of the whole eternal
> leap second imbroglio.
> 
> Guy has, I think, tried to carefully decouple two aspects of the
> question:
> 
> A. Does your time scale count leap seconds or not, and
> B. Does your representation use broken-down times ("calendar +
>   clock"), or monotonic counts of seconds since an epoch?

What does "count leap seconds" mean in this context?

If you have a B-style representation, it means "does that count increase during a positive leap second?" (we'll ignore negative leap seconds here).

If you have an A-style representation, and it's TAI or UTC, it "counts leap seconds" in the sense that "the clock value changes even for the leap second and, if it overflows, the calendar value changes as well".  The difference between TAI and UTC in that regard is in the fashion in which the clock value changes.  The clock value changes in the same fashion, all the time, in TAI; it doesn't change in the same fashion, all the time, in UTC, *and the way in which it will change in the future is not predictable past a certain point* - you have to wait for an IERS Bulletin C to come out for that point before you can predict.

So are A-style representations defined for both UTC and TAI?  ITU-R Recommendation TF.460-6 says:

	2 Leap-seconds

	2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September.

	2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex 3).

but where 1) the form HHh Mmm SSs for time stamps specified for UTC, 2) is that also specified for TAI?, 3) is it stated anywhere how days are indicated in this context (YYYY-MM-DD?  DD MMMMM YYYY?)

What that Recommendation says is

	B International atomic time (TAI)

	The international reference scale of atomic time (TAI), based on the second (SI), as realized on the rotating geoid, is formed by the BIPM on the basis of clock data supplied by cooperating establishments. It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 (adopted by the CGPM 1971).

	C Coordinated universal time (UTC)

	UTC is the time-scale maintained by the BIPM, with assistance from the IERS, which forms the basis of a coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI but differs from it by an integer number of seconds.

	The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leap-seconds) to ensure approximate agreement with UT1.

which, at most, says that, *for example*, TAI is in the form of days (presumably days that are always exactly 86400 seconds long)), hours. minutes, and seconds from "the origin 1 January 1958" (does that mean "midnight, 1 January 1958"?).  If, in fact, "days" correspond to exactly-86400-second-long days, and "the origin 1 January 1958" is "midnight, 1 January 1958", TAI could also be represented as a scale of seconds since the origin 1 January 1958, with conversion between those two scales being straightforward (division and remainder to go from the second scale to the first, multiplication and addition to go from the first scale to the second, given that there are no leap seconds, month lengths, or leap years to worry about).

Can TAI also be represented as an absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day?  If so, are there any specified rules for that?  (Conversion to or from that scale from either of the scales mentioned in the previous paragraph is a little more work, as you'd have to worry about month lengths and leap years).

And in what ways could the UTC scale be represented?  The "differs from it by an integral number of seconds", with the difference varying over time, would presumably be a difference between the "absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day" representations of TAI or UTC, given that "It corresponds exactly in rate with TAI" means that, for the "days, hours, minutes and seconds from the origin 1 January 1958" definition of TAI, every one of those seconds occurs in UTC as well, so if you represent UTC as a count of days, hours, minutes, and seconds from some origin, or just as a count of seconds from that origin, the difference between the two scales, in seconds, is the difference between the origins, in seconds.

Annex 3 of that recommendation, "Dating of events in the vicinity of a leap-second", shows events being dated "30 June, 23h 59m 60.6s UTC"; as it's an example, the year is omitted, so presumably the "30 June" would have a year number after it for a real event, i.e. an absolute Gregorian-style date.

> Me, I would say that (1) and (4) are completely compatible --
> they're two different representations for the same underlying
> time scale.  You can perfectly interconvert between them using
> the same algorithm Posix defines for time_t.
> 
> When it comes to UTC, however, (2) and (3) are most definitely
> not compatible.  Personally, I believe that (2) is the *only*
> way to represent UTC.  I believe -- Posix time_t most assuredly
> notwithstanding -- that (3) is an abomination.

(2) and (3) are both problematic.

With (2), time stamps for events defined to occur at a specified sufficiently large number of seconds in the future cannot be predicted.  That includes all events with times specified by a (1)-style or (4)-style time stamp if those times go past what the IERS has specified.

With (3), some time stamps cannot be specified - including time stamps for events in the *past*, such as an event occurring on 30 June 2015 at 23h 59m 60s UTC.

> If you try to represent UTC using a monotonic count of seconds,
> you have to either (a) ignore leap seconds after all (as Posix
> does, but which totally contradicts those words "with the count
> including leap seconds" in the definition of (3)), or (b) use
> a kludgey and non-obvious (and non-Posix) mapping between your
> monotonic time and broken-down calendar+time, a mapping which
> always requires you to have a perfect leap second table available.
> 
> And in fact, if you try to do (b), I believe that you are *not*
> really doing UTC, after all -- you are basically doing TAI
> (perhaps with a slightly different epoch), and misleadingly
> calling it UTC.

If you are doing (a), you're not doing UTC either, given that POSIX can't distinguish between, say, 30 June 2015, 23h 59m 59s UTC and 30 June 2015, 23h 59m 60s UTC.

(a) can't even do UTC correctly for *past* events.  (b) *can* do UTC correctly for past events if you have a leap second table available that includes all announced leap seconds as of now - I think there may even be some sample code to do that. :-)  What it can't do is handle UTC for *future* events, as a "perfect" leap second table requires perfect knowledge of the future, and we all what somebody (Karl Kristian Steincke?) said about predicting:

	http://quoteinvestigator.com/2013/10/20/no-predict/

TLDR: "you can't do UTC for arbitrary times in the future without running the risk of having to adjust something before the event".  (Well, with sufficient thiotimoline used in your clock you might. :-))

> You are engendering just as much confusion as
> the Posix time_t definition does.  A monotonic count of seconds
> is simply not an appropriate representation for UTC.  The only
> proper representation(s) of UTC are those that separate the date
> from the time, so that they can cleanly, honestly, openly, and
> explicitly accommodate those pesky days of other than 86400
> seconds.

You cannot predict what the broken-down UTC label for an event N seconds in the future will be, if N is sufficiently large that it will be past a point at which a leap second might be introduced and for which the IERS hasn't announced whether there will be a leap second or not - the UTC label depends on whether a leap second will be inserted there or not.

So UTC - and local civil time, if based on UTC - isn't a good way to label events sufficiently far in the future (as in, right now, any event happening at or after the end of 30 June 2020), if you can't live with being a few seconds off.

So if we want to describe *any* timekeeping scheme that represents times in a format that is, or can trivially be converted to and from without loss of information, a count of seconds, including leap seconds, since some epoch, as "TAI", OK.  That does *not*, of course, mean that the epoch needs to be expressed as a TAI time stamp; "seconds, including leap seconds, since 1970-01-01 00:00:00 UTC" would then be a representation of TAI (given that we know what instant of time was labeled 1970-01-01 00:00:00 UTC - no knowledge of the future is needed there).

From kre at munnari.OZ.AU  Sun Dec 15 00:04:04 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Sun, 15 Dec 2019 07:04:04 +0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
Message-ID: <1667.1576368244@jinx.noi.kre.to>

The problem we have in the current discussion, is that once again,
we're trying to over simplify time - make time work the way we think
it should work, rather than the way it does.

It makes no sense (to me) at all to convert TAI into any kind of
(currently used) calendar type measurements - the calendars we use
are designed to match astronomical reality (the various rotations of
the earth) and those things just don't take constant periods, even
though they're close.   But that's what we have decided we want from
our calendar system - we want it to alwqays be summer in January, and
winter in July (those unfortunate enough to be in the wrong hemisphere
can adapt as needed), and TAI (alone, withough some kinds of
corrections) simply does not provide that.   If you want some kind of
calendar for TAI you'd be better to convert it to stardates or something.

Certainly I don't think it makes any rational sense to have different
length "years" (regular years and leap years, with a bizarre rule about
which years are which) in TAI - though it is certainly sensible to have a
unit bigger than seconds in which to measure lengthy periods (though I doubt
anything approximating a year is really big enough - TAI is useful for
measuring short durations (something we would conventionally count in
tiny fractions of a second up to hours), and very long ones (millions of
years, and longer), but not so much for anything in between).

What we really need to do is recognise that there is not (rather should
not be) just one definition (one unit) "a second" - there are two entirely
different things we use commonly, which just happen to be so close together
that we have tried to force them to be the same thing.

One is the thing TAI uses (and UTC with leap second corrections) - which is
a period defined by something that we believe to be fixed - always the exact
same duration, and so can be used for comparing durations from measurements
collected separately,

The other is 1/84600 of a day (a bizarre choice, but never mind) where a
day is defined according to the (varying) rotations of the earth, and hence
the second is not a fixed length, but a variable one.   That's the POSIX
second (time_t) value, but is also how humans have measured time ever since
we started doing it - initially it wasn't understood that the length of a
day wasn't constant (as it so nearly is) but 60 seconds a minute, 60
minutes an hour, 24 hours a day, (ie: 86400 seconds a day) is what has been
used for a long time now, (with the more precise measurements appearing as
we gained the ability to measure them, sundials to be able to measure house,
hourglasses to meaure minutes, and fractions thereof somtimes, ...)

We really should be using two different names for these two different things,
rather than trying to pretend that a "second" can be defined which suits
both purposes.

But until a large enough fraction of the population need to routinely
deal with the differences, I don't see that happening.   Certainly it
doesn't help to continually try and force one another to adopt only one
way of measuring time, as there is (as long as we keep anything like our
current calendars) no way to make that work simply - nothing anyone would
be prepared to attempt to implement - that is even if one can accept that
any current calendar calculations are even close to simple.

kre


From scs at eskimo.com  Sun Dec 15 00:56:42 2019
From: scs at eskimo.com (Steve Summit)
Date: Sat, 14 Dec 2019 19:56:42 -0500
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <1667.1576368244@jinx.noi.kre.to>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <1667.1576368244@jinx.noi.kre.to>
Message-ID: <2019Dec14.1956.scs.0008@quinine2.home>

Robert Elz wrote:
> It makes no sense (to me) at all to convert TAI into any kind of
> (currently used) calendar type measurements -

Fair enough.

> Certainly I don't think it makes any rational sense to have different
> length "years" (regular years and leap years, with a bizarre rule about
> which years are which) in TAI - though it is certainly sensible to have
> a unit bigger than seconds in which to measure lengthy periods...

Vernor Vinge has a wonderful set of SF novels ("A Deepness in the
Sky", etc.), set in the far future, in which they measure time in
kiloseconds, megaseconds, etc.  There's also this marvelous
passage concerning legacy software:

	Via a million million circuitous threads of inheritance,
	many of the oldest programs still ran in the bowels of
	the Qeng Ho system.  Take the Traders' method of timekeeping.
	The frame corrections were incredibly complex -- and down
	at the very bottom of it was a little program that ran a
	counter.  Second by second, the Qeng Ho counted time from
	the instant that a human had first set foot on Old Earth's
	moon.  But if you looked at it still more closely...
	the starting instant was actually about fifteen million
	seconds later, the 0-second of one of Humankind's first
	computer operating systems.

> What we really need to do is recognise that there is not [...] just one
> definition (one unit) "a second" - there are two entirely different
> things we use commonly [...] One is the thing TAI uses [...] The other
> is 1/84600 of a day [...] where a day is defined according to the
> (varying) rotations of the earth, and hence the second is not a fixed
> length, but a variable one.  That's the POSIX second (time_t) value [...]

I don't entirely disagree, and indeed bringing UT1 to bear is an
attractive way of trying to rescue the benighted Posix definition,
but time_t is certainly not defined that way now, and I'm not aware
of anyone implementing it that way!  time_t seconds really are
UTC/TAI seconds (except, of course, when they're not).

[But perhaps what you're saying is that redefining time_t as UT1
is part of "What we really need to do".]

From kre at munnari.OZ.AU  Sun Dec 15 05:16:46 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Sun, 15 Dec 2019 12:16:46 +0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <2019Dec14.1956.scs.0008@quinine2.home>
References: <2019Dec14.1956.scs.0008@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
Message-ID: <28493.1576387006@jinx.noi.kre.to>

    Date:        Sat, 14 Dec 2019 19:56:42 -0500
    From:        scs at eskimo.com (Steve Summit)
    Message-ID:  <2019Dec14.1956.scs.0008 at quinine2.home>

  | [But perhaps what you're saying is that redefining time_t as UT1
  | is part of "What we really need to do".]

First, part ofmy belief is that nothing that POSIX (or the C std)
has related to time is even close to adequate.

For time_t what I mean is that it should not survive as it is, we need
(just for "seconds" time counters) two entirely different things,  which
keep track of the different ways we count time, differently.  Currently
this is fudged with how one obtains the time_t (CLOCK_MONOTONIC, CLOCK_REALTIME
etc) but because they all produce the same type (time_t) they can all
be processed the same way - so a CLOCK_MONOTONIC result can be handed to 
localtime() which makes no rational sense at all.

kre


From john.haxby at oracle.com  Sun Dec 15 13:03:44 2019
From: john.haxby at oracle.com (John Haxby)
Date: Sun, 15 Dec 2019 13:03:44 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <28493.1576387006@jinx.noi.kre.to>
References: <2019Dec14.1956.scs.0008@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <28493.1576387006@jinx.noi.kre.to>
Message-ID: <926A7281-FDB4-49CC-8A85-7B55AF7DB65D@oracle.com>



> On 15 Dec 2019, at 05:16, Robert Elz <kre at munnari.OZ.AU> wrote:
> 
>    Date:        Sat, 14 Dec 2019 19:56:42 -0500
>    From:        scs at eskimo.com (Steve Summit)
>    Message-ID:  <2019Dec14.1956.scs.0008 at quinine2.home>
> 
>  | [But perhaps what you're saying is that redefining time_t as UT1
>  | is part of "What we really need to do".]
> 
> First, part ofmy belief is that nothing that POSIX (or the C std)
> has related to time is even close to adequate.
> 
> For time_t what I mean is that it should not survive as it is, we need
> (just for "seconds" time counters) two entirely different things,  which
> keep track of the different ways we count time, differently.  Currently
> this is fudged with how one obtains the time_t (CLOCK_MONOTONIC, CLOCK_REALTIME
> etc) but because they all produce the same type (time_t) they can all
> be processed the same way - so a CLOCK_MONOTONIC result can be handed to 
> localtime() which makes no rational sense at all.
> 
> kre
> 

I completely agree.  IIRC, Posix defines the time returned by various things as "since approximately 1970-01-01 00:00:00 UTC" or "since an undefined epoch".   Basically, the first time_t roughly gives the current wall-clock time in the Greenwich observatory in northern hemisphere winter (you can offset it to whatever timezone you think you are in).   The second time_t gives you a reliable way of measuring elapsed time[1].

The central assumption of posix time-of-day is that a day is exactly 86400 seconds which is handy if you're doing quick and dirty coding: but how long does sleep(86400) sleep for over a leap second?  (There are good, bad and ugly possible answers.  And accurate ones.).

I think Go has the right idea.   A time.Time object works for both elapsed and wall-clock time by holding two possible values.   So when there's been a leap second, noon-to-noon should show an elapsed time of 86401 seconds (I wonder if it does?) and if you want to sleep() from noon to noon you need to sleep the calculated interval, not 86400.

It's a mess.

jch



[1] a certain database is, finally, using that to measure elapsed time.

From michael.h.deckers at googlemail.com  Sun Dec 15 13:22:55 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Sun, 15 Dec 2019 13:22:55 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <1667.1576368244@jinx.noi.kre.to>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
Message-ID: <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>


 ?? On 2019-12-15 00:04, Robert Elz wrote:

> It makes no sense (to me) at all to convert TAI into any kind of
> (currently used) calendar type measurements - the calendars we use
> are designed to match astronomical reality (the various rotations of
> the earth) and those things just don't take constant periods, even
> though they're close.   But that's what we have decided we want from
> our calendar system - we want it to alwqays be summer in January, and
> winter in July (those unfortunate enough to be in the wrong hemisphere
> can adapt as needed), and TAI (alone, withough some kinds of
> corrections) simply does not provide that.   If you want some kind of
> calendar for TAI you'd be better to convert it to stardates or something.


 ??? The notation of values of TAI using the Gregorian calendar is helpful
 ??? when comparing time scales. For instance, in the recent BIPM definition
 ??? of TAI, as sanctioned by the 26th CGPM 2018, online at
 ??? [https://www.bipm.org/en/CGPM/db/26/2/], we read:

 ??????? "TT - TAI = 32.184 s exactly at 1 January 1977, 0h TAI
 ???????? at the geocentre, in order to ensure continuity
 ???????? of TT with Ephemeris Time"


> ....
> What we really need to do is recognise that there is not (rather should
> not be) just one definition (one unit) "a second" - there are two entirely
> different things we use commonly, which just happen to be so close together
> that we have tried to force them to be the same thing.
>
> One is the thing TAI uses (and UTC with leap second corrections) - which is
> a period defined by something that we believe to be fixed - always the exact
> same duration, and so can be used for comparing durations from measurements
> collected separately,
>
> The other is 1/84600 of a day (a bizarre choice, but never mind) where a
> day is defined according to the (varying) rotations of the earth, and hence
> the second is not a fixed length, but a variable one.   That's the POSIX
> second (time_t) value, but is also how humans have measured time ever since
> we started doing it - initially it wasn't understood that the length of a
> day wasn't constant (as it so nearly is) but 60 seconds a minute, 60
> minutes an hour, 24 hours a day, (ie: 86400 seconds a day) is what has been
> used for a long time now, (with the more precise measurements appearing as
> we gained the ability to measure them, sundials to be able to measure house,
> hourglasses to meaure minutes, and fractions thereof somtimes, ...)
>
> We really should be using two different names for these two different things,
> rather than trying to pretend that a "second" can be defined which suits
> both purposes.


 ??? I disagree.

 ??? You are right that the time scales UT1 and TAI have different 
rates; and
 ??? there are several other time scales used in astronomy (eg TCB, TCG, 
TDB)
 ??? with still other rates. This is caused by physics (not just by the
 ??? tradition of mean solar time derived from Earth rotation).

 ??? Astronomers want to be able to compare these time scales and convert
 ??? between them, hence they _must_ express their values in common units.
 ??? Even the mere expression that the time scales differ in rate requires
 ??? the use of common units.

 ??? For instance, the differential quotient d(TAI - UT1)/d(UT1) is a
 ??? measure of the speed of rotation of the Earth called "excess length
 ??? of day" (it actually was negative, -20 ?s/d on 2019-12-11).
 ??? We cannot compute TAI - UT1 unless the values of TAI and UT1 are
 ??? expressed in the same units. Still another non-SI time unit would
 ??? only confuse the issue.

 ??? Beyond that, the quantity "mean solar second" = d(TAI)/d(UT1)?(1 s)
 ??? would be a bad choice for a unit since d(TAI)/d(UT1) changes
 ??? unpredictably over time.

 ??? In the presence of different time scales, it certainly is necessary
 ??? to designate the time scale in which a specific datetime was
 ??? observed; in ISO 8601 notation, the suffix Z indicates a UTC value,
 ??? a suffixed offset indicates a local civil time scale derived from
 ??? UTC; and otherwise, an appended time scale acronym (as above) is
 ??? often used to indicate the time scale.

 ??? Michael Deckers.


From Brian.Inglis at SystematicSw.ab.ca  Sun Dec 15 23:52:25 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Sun, 15 Dec 2019 16:52:25 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <2019Dec14.1956.scs.0008@quinine2.home>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <2019Dec14.1956.scs.0008@quinine2.home>
Message-ID: <1de2e8e4-3df0-8098-670f-787a8eb62ea3@SystematicSw.ab.ca>


On 2019-12-14 17:56, Steve Summit wrote:
> Vernor Vinge has a wonderful set of SF novels ("A Deepness in the
> Sky", etc.), set in the far future, in which they measure time in
> kiloseconds, megaseconds, etc.  There's also this marvelous
> passage concerning legacy software:

> Via a million million circuitous threads of inheritance, many of the oldest
> programs still ran in the bowels of the Qeng Ho system.  Take the Traders'
> method of timekeeping. The frame corrections were incredibly complex -- and
> down at the very bottom of it was a little program that ran a counter.
> Second by second, the Qeng Ho counted time from the instant that a human had
> first set foot on Old Earth's moon.  But if you looked at it still more
> closely... the starting instant was actually about fifteen million seconds
> later, the 0-second of one of Humankind's first computer operating systems.

Should not make assumptions about other cultures, as they may be upset.
Now, would more likely have been 1.5 billion seconds later:

$ TZ=UTC date -d 2019-01-03\ 02:26 +%s # Chang'e 4 landing
1546482360

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

From Brian.Inglis at SystematicSw.ab.ca  Mon Dec 16 00:08:04 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Sun, 15 Dec 2019 17:08:04 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <1de2e8e4-3df0-8098-670f-787a8eb62ea3@SystematicSw.ab.ca>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <2019Dec14.1956.scs.0008@quinine2.home>
 <1de2e8e4-3df0-8098-670f-787a8eb62ea3@SystematicSw.ab.ca>
Message-ID: <46715fcb-4c80-0da3-9cef-15c9858420ec@SystematicSw.ab.ca>

On 2019-12-15 16:52, Brian Inglis wrote:
> Should not make assumptions about other cultures, as they may be upset.
[Upset meaning rendered incorrect rather than feeling annoyed.]
> Now, would more likely have been 1.5 billion seconds later:
> $ TZ=UTC date -d 2019-01-03\ 02:26 +%s # Chang'e 4 landing
> 1546482360

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

From eggert at cs.ucla.edu  Mon Dec 16 00:53:06 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Sun, 15 Dec 2019 16:53:06 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <1667.1576368244@jinx.noi.kre.to>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
Message-ID: <21e3e0f0-2b83-3414-9ed6-40e7c5572259@cs.ucla.edu>

On 12/14/19 4:04 PM, Robert Elz wrote:
> It makes no sense (to me) at all to convert TAI into any kind of
> (currently used) calendar type measurements - the calendars we use
> are designed to match astronomical reality

Well, sort of. Astronomers normally match astronomical reality only by using the
technology of 45 BC, because they define a "year" to be the Julian year (31.5576
Ms) when, for example, they estimate the Big Bang as being 13.798 ? 0.037
billion years ago. Paleontologists are similar. Archaelogists too, I expect (at
least for anything more than a few centuries old).

For the Big Bang estimate, the difference between Julian and Gregorian is less
than the confidence interval, so the distinction doesn't matter much. It's like
when someone says "a million years ago", they don't much care whether this means
a million years before 2019 or a million years before 2020.

If we wanted to stick to "astronomical reality" it would not be a good idea to
count Earth days, as the length of the Earth day was only four hours or so back
when the the Earth was formed (at least, according to estimates by Takanori
Sasaki <http://www.iea.usp.br/en/news/when-a-day-lasted-only-four-hours>). We'd
be better off counting Earth years, as the length of Earth's year hasn't changed
as much since then. Of course even then our clocks would go back only 4.5
billion years ago, and would stray a bit from astronomical years for other
relatively-minor reasons (such as, the Sun's mass is constantly declining
slightly, which means the Earth year length is constantly growing slightly).

From guy at alum.mit.edu  Mon Dec 16 03:49:40 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sun, 15 Dec 2019 19:49:40 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <28493.1576387006@jinx.noi.kre.to>
References: <2019Dec14.1956.scs.0008@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <28493.1576387006@jinx.noi.kre.to>
Message-ID: <EF159889-A6B3-4DE0-AA6F-DD7783752828@alum.mit.edu>

On Dec 14, 2019, at 9:16 PM, Robert Elz <kre at munnari.OZ.AU> wrote:

> For time_t what I mean is that it should not survive as it is, we need
> (just for "seconds" time counters) two entirely different things,  which
> keep track of the different ways we count time, differently.  Currently
> this is fudged with how one obtains the time_t (CLOCK_MONOTONIC, CLOCK_REALTIME
> etc) but because they all produce the same type (time_t) they can all
> be processed the same way - so a CLOCK_MONOTONIC result can be handed to 
> localtime() which makes no rational sense at all.

For the purposes of logging events as they happen (meaning that, assuming the clock isn't incorrectly set ahead, all time stamps quickly become time stamps in the past), a value that 1) is a count of seconds (and perhaps fractional seconds) that have elapsed since some defined epoch, including leap seconds, and 2) can be converted to YYYY-MM-DD HH:MM:SS.SSSS is useful.

That way, 1) you can easily calculate time deltas between those events and 2) you can find out when a particular event happened.

(Some may already have guessed that I'm thinking of, among other things, network traffic captures here.)

From guy at alum.mit.edu  Mon Dec 16 03:57:23 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sun, 15 Dec 2019 19:57:23 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
Message-ID: <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>

On Dec 15, 2019, at 5:22 AM, Michael H Deckers <michael.h.deckers at googlemail.com> wrote:

>     The notation of values of TAI using the Gregorian calendar is helpful
>     when comparing time scales.

So how is that defined?

Do you just take a UTC value for the same instant, add the current TAI - UTC delta to it - and, for overflow (meaning "resulting seconds > 59 or minutes > 59 or...), "carry into" the calendar date, so that an event that took place at the end of 2018, with a UTC label, took place at the beginning of 2019, with a TAI label?

From michael.h.deckers at googlemail.com  Mon Dec 16 13:43:56 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Mon, 16 Dec 2019 13:43:56 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
 <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
Message-ID: <39682719-ac09-47ba-a921-1e92026c1bc8@googlemail.com>


On 2019-12-16 03:57, Guy Harris wrote:
> On Dec 15, 2019, at 5:22 AM, Michael H Deckers <michael.h.deckers at googlemail.com> wrote:
>
>>      The notation of values of TAI using the Gregorian calendar is helpful
>>      when comparing time scales.
> So how is that defined?
>
> Do you just take a UTC value for the same instant, add the current TAI - UTC delta to it - and, for overflow (meaning "resulting seconds > 59 or minutes > 59 or...), "carry into" the calendar date, so that an event that took place at the end of 2018, with a UTC label, took place at the beginning of 2019, with a TAI label?


 ?? Yes. If TAI was 1977-01-01, then TAI - UTC was 15 s, so that
 ?? UTC was 1977-01-01 - 15 s = 1976-12-31T23:59:45.

 ?? A calendar date just denotes a point on the time axis; and
 ?? a time scale assigns a point on the time axis to each point
 ?? of a region of spacetime (on which the time scale is defined).

 ????? That is a "time scale" in the astronomical sense of the word,
 ????? where TCB, TCG, TDB, TT, UTC, UT1, UT2, and local civil times
 ????? are time scales. A "geological time scale" is something else;
 ????? IEC 60050 has additional meanings for "time scale".

 ?? A calendar is not restricted to the notation of values of one
 ?? specific time scale, and points on the time axis can also be
 ?? denoted by other means: the notations
 ?????? 2000-01-01,
 ?????? JD 2451 544.5
 ?????? MJD 40 587 + 946 684 800 s
 ?????? -50 a B.P.
 ?? all denote the same point on the time axis.

 ?? Michael Deckers.


From clive at davros.org  Mon Dec 16 14:10:21 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 14:10:21 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
References: <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
 <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
Message-ID: <20191216141021.GD490@davros.org>

Guy Harris said:
>>     The notation of values of TAI using the Gregorian calendar is helpful
>>     when comparing time scales.
> 
> So how is that defined?
> 
> Do you just take a UTC value for the same instant, add the current TAI - UTC delta to it - and, for overflow (meaning "resulting seconds > 59 or minutes > 59 or...), "carry into" the calendar date, so that an event that took place at the end of 2018, with a UTC label, took place at the beginning of 2019, with a TAI label?

No.

You take a Gregorian calendar (by default; in principle you could use
Julian or something else) and use it to count *all* SI seconds, so that
every day has exactly 86400 seconds in it. It works the same way as UT1,
but without the unpredictable-length "seconds".

You can convert that to UTC by subtracting the relevant (not "current")
TAI-UTC delta and doing correct carries, remembering to handle the edge
cases when the delta changes.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

From clive at davros.org  Mon Dec 16 14:36:11 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 14:36:11 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
Message-ID: <20191216143611.GE490@davros.org>

Guy Harris said:
> On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:
> 
> > Guy Harris said:
> >>> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
> >>> internally for all timestamps, leaving the leap second mess to the
> >>> periphery.
> >> 
> >> Yes, section 5.1.1 "Time" of
> >> 
> >> 	https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634

It's a while since I was involved in Mesh, and it's possible that they've
managed to mess things up since then. But, let's see ...

> >> specifies that the base representation of times is the number of seconds that have elapsed since 1999-12-31T23:59:28 UTC. :-) :-) :-) :-) :-)
> > 
> > Yes. But ...
> > 
> >> (I.e., the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as an instant of time that has more zeroes in the way it's represented as TAI than in the way it's represented as UTC.  If it had been defined as the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC. that would still "leave the leap second mess to the periphery"; it would just mean that the count of seconds would be 32 seconds lower.

Okay, that statement does indeed pick a convenient epoch for counting
seconds. It means the the function to map the 40-bit seconds count (and 8
bit subsecond count) to a "broken-down" time in TAI is easy.

>>> By the way, how is TAI, represented as YYYY-MM-DDTHH:MM:SS TAI, defined?  Does it have a Gregorian-style calendar made up entirely of 86400-second days, so that most years are exactly 31,536,000 seconds long, with some years being exactly 31,622,400 seconds long?
>> Yes, and that's a big part of "avoiding the mess" - you don't worry about
>> time zones *or* leap seconds.
> ...unless you need to convert a Bluetooth Mesh time stamp to UTC.

Which is done "on the periphery". Note the use of zero in various fields to
indicate that the device doesn't have zone or leap second information.

> And the same would be true if it counted the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC.

Also true, but it seems cleaner to have the epoch be a round point in TAI,
rather than in UTC, given that you're using TAI internally. Note the
following paragraph:

"To allow Mesh devices to refer to UTC or local times, devices need to be
aware of the past, present, and predicted changes to the TAI-UTC Delta (the
number of seconds between TAI and UTC) and to the local time zone offset
(e.g., in Seattle, USA, the local time is exactly 7 hours behind UTC for
part of the year and 8 hours behind UTC for the rest of the year). Because
these two values can change at any time for physical or political reasons,
they are not hard-coded into this specification. Instead, they are
communicated to all nodes in the mesh provided that at least one device has
the information."

More "periphery" stuff, since most uses won't use those offsets.

An algorithm is also given for converting TAI seconds since the epoch to a
UTC "broken-down" time. Setting E and F to zero will give you a TAI
"broken-down" time.

>>> 	1) "TAI-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, with non-leap years being exactly 31,536,000 seconds long and leap years being exactly 31,622,400 seconds long, so that SS goes from 00 to 59, never to 60;
> > 
>> That's what Mesh uses when handling a "broken-down" time. Hence "TAI".
> 
> Preview doesn't report the word "broken" anywhere in the spec.

The term "broken-down time" is common - or, at least, I thought it was - to
refer to the "YYYY-MM-DD hh:mm:ss" format as opposed to "(some) (sort-of)
seconds past the epoch".

But it's possible that they stopped doing this after I stopped being
involved.

> The times discussed in 5.1.4.2 Schedule Register presumably are, when no wildcards are involved, local dates/times, with a time stamp being a Gregorian-style YY-MM-DDTHH:MM:SS, and with non-leap years being either 31,536,000, 31,536,001, or 31,536,002 seconds long, and with leap years being either 31,622,400, 31,622,401, or 31,622,402 seconds long (which might disagree with most real-world clocks, as those clocks probably behave as if you had a UTC calendar and a clock that ticks like TAI, in the sense that it always goes from 23:59:59 to 00:00:00, but that's some number of seconds off from TAI).

The Scheduler is part of the app you run on your phone, or whatever. As it
says, the fields are in local time.

> The Time state includes TAI-UTC Delta Current, TAI-UTC Delta New, and TAI of Delta Change; those require dealing with leap seconds.

But those are only generated by the device that knows them and are only
used to present values in local time or to convert local time to SI seconds
past the epoch. Most devices in the mesh don't do that.

The Scheduler app converts the local times into TAI-past-the-epoch to send
out "turn on at this time" messages.

> >> 	3) counts of seconds since a specified epoch, with the count including leap seconds;
> > 
> > And that's what Mesh uses when just counting seconds. I agree that it
> > doesn't matter whether you could TAI seconds or UTC seconds, because
> > they're exactly the same.

s/could/call them/

In fact, "SI seconds" might have been better. One reason for using "TAI"
rather than "UTC" is that it makes it clear that all seconds are included
rather than the Posix perversion of calling it UTC and then ignoring some
of them.

> (The point is that, in a time stamping mechanism that stamps times with counts of seconds since an epoch, whether the count includes leap seconds is independent of whether the specification for the epoch includes the letters "T", "A", and "I" in sequence with no spaces between them or includes the letters "U", "T", and "C" in sequence with no spaces between them.)

True, *if* people don't misunderstand.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

From clive at davros.org  Mon Dec 16 14:56:03 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 14:56:03 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <2019Dec14.1100.scs.0003@quinine2.home>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
Message-ID: <20191216145603.GF490@davros.org>

Steve Summit said:
>> The times discussed in 5.1.4.2 Schedule Register presumably are [...]
>> with non-leap years being either 31,536,000, 31,536,001, or 31,536,002
>> seconds long
> 
> I wouldn't presume that at all.  If it's doing TAI, if it's not
> counting leap seconds, why would you presume years of other than
> 31,536,000 or 31,622,400 seconds?

Those ones are in local time, so have years of varying lengths (*cough*
1751 and 1752 *cough*).

> Guy has, I think, tried to carefully decouple two aspects of the
> question:
> 
> A. Does your time scale count leap seconds or not, and

This depends on what you mean by a leap second. And that is part of the
problem.

> B. Does your representation use broken-down times ("calendar +
>    clock"), or monotonic counts of seconds since an epoch?
>
> I agree that those issues are orthogonal.  (I'm also going to
> ignore for now the side question of whether the epoch mentioned
> in "B" is defined as a UTC or TAI timestamp.)

No. They look orthogonal at first glance, but they aren't.

> So when Guy said "there are at least four different flavors of
> time stamp", I think his flavors map onto my two aspects A and B
> with this little truth table:
> 
>   A    B
>  no   b-d   1) TAI-style calendar+clock
>  yes  b-d   2) UTC-style calendar+clock
>  no   mono  4) counts of non-leap seconds since a specified epoch
>  yes  mono  3) counts of seconds since a specified epoch,
>                with the count including leap seconds

[I'm wondering if that intended to have 3 before 4, based on the following
text.]

What I would have is, rather, the following:

C: Does your time scale count every second exactly once? A "no" answer
means that some seconds are not counted or are counted twice.
D: Does your time scale:
   (1) use a monotonic count of seconds since some epoch
   (2) use a broken-down style with the seconds field always stepping from
       59 to 00 at the end of the minute
   (3) use a broken-down style with the seconds field stepping from 58,
       59, or 60 to 00 at the end of the minute, depending on the exact
       date-time.

C yes D 1 is a count of SI seconds since the epoch. I called it a count of
TAI seconds to avoid people confusing it with:

C no  D 1, which is Posix time_t and which some people erroneously think is
a count of UTC seconds since the epoch. (It is approximately a count of UT1
seconds since the epoch, but I don't want to get into the SI versus sideral
seconds debate).

C yes D 2 is TAI broken-down format.

C no  D 2 is Posix broken-down format.

C yes D 3 is UTC broken-down format.

C no  D 3 is, I hope, never used.

> Me, I would say that (1) and (4) are completely compatible --
> they're two different representations for the same underlying
> time scale.  You can perfectly interconvert between them using
> the same algorithm Posix defines for time_t.

That algorithm can convert between D 1 and D 2 for either C case, so long
as you don't mix them up.

> When it comes to UTC, however, (2) and (3) are most definitely
> not compatible.  Personally, I believe that (2) is the *only*
> way to represent UTC.  I believe -- Posix time_t most assuredly
> notwithstanding -- that (3) is an abomination.

UTC is C yes D 3.

> If you try to represent UTC using a monotonic count of seconds,
> you have to either (a) ignore leap seconds after all (as Posix
> does, but which totally contradicts those words "with the count
> including leap seconds" in the definition of (3)), or (b) use
> a kludgey and non-obvious (and non-Posix) mapping between your
> monotonic time and broken-down calendar+time, a mapping which
> always requires you to have a perfect leap second table available.

Yes. I agree.

> And in fact, if you try to do (b), I believe that you are *not*
> really doing UTC, after all -- you are basically doing TAI
> (perhaps with a slightly different epoch), and misleadingly
> calling it UTC.  You are engendering just as much confusion as
> the Posix time_t definition does.  A monotonic count of seconds
> is simply not an appropriate representation for UTC.  The only
> proper representation(s) of UTC are those that separate the date
> from the time, so that they can cleanly, honestly, openly, and
> explicitly accommodate those pesky days of other than 86400
> seconds.

I think I agree with that as well.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

From sla at ucolick.org  Mon Dec 16 15:07:12 2019
From: sla at ucolick.org (Steve Allen)
Date: Mon, 16 Dec 2019 07:07:12 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191216141021.GD490@davros.org>
References: <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
 <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
 <20191216141021.GD490@davros.org>
Message-ID: <20191216150712.GA8966@ucolick.org>

On Mon 2019-12-16T14:10:21+0000 Clive D.W. Feather hath writ:
> You take a Gregorian calendar (by default; in principle you could use
> Julian or something else) and use it to count *all* SI seconds, so that
> every day has exactly 86400 seconds in it. It works the same way as UT1,
> but without the unpredictable-length "seconds".

In 1968 between a pair of meetings the atomic clock and CCIR folks
ascertained that they could not use that scheme in broadcast time
signals, and that is when and why the notion of the leap second came
into being.

--
Steve Allen                    <sla at 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           https://www.ucolick.org/~sla/  Hgt +250 m

From clive at davros.org  Mon Dec 16 16:26:24 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 16:26:24 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
Message-ID: <20191216162624.GA97598@davros.org>

Guy Harris said:
> So are A-style representations defined for both UTC and TAI?  ITU-R Recommendation TF.460-6 says:
> 
> 	2 Leap-seconds
> 
> 	2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September.
> 
> 	2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex 3).
> 
> but where 1) the form HHh Mmm SSs for time stamps specified for UTC, 2) is that also specified for TAI?, 3) is it stated anywhere how days are indicated in this context (YYYY-MM-DD?  DD MMMMM YYYY?)

Hmm.

> What that Recommendation says is
> 
> 	B International atomic time (TAI)
> 
> 	The international reference scale of atomic time (TAI), based on the second (SI), as realized on the rotating geoid, is formed by the BIPM on the basis of clock data supplied by cooperating establishments. It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 (adopted by the CGPM 1971).
> 
> 	C Coordinated universal time (UTC)
> 
> 	UTC is the time-scale maintained by the BIPM, with assistance from the IERS, which forms the basis of a coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI but differs from it by an integer number of seconds.
> 
> 	The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leap-seconds) to ensure approximate agreement with UT1.
> 
> which, at most, says that, *for example*, TAI is in the form of days (presumably days that are always exactly 86400 seconds long)), hours. minutes, and seconds from "the origin 1 January 1958" (does that mean "midnight, 1 January 1958"?).

That says rather less than I expected. Equally, it doesn't say that much
about UTC either.

I would have thought "differs from it by an integer number of seconds" only
makes sense if they use the same representation when calcualting the
difference.

> If, in fact, "days" correspond to exactly-86400-second-long days,

I think they do.

> and "the origin 1 January 1958" is "midnight, 1 January 1958", TAI could also be represented as a scale of seconds since the origin 1 January 1958, with conversion between those two scales being straightforward (division and remainder to go from the second scale to the first, multiplication and addition to go from the first scale to the second, given that there are no leap seconds, month lengths, or leap years to worry about).

Okay, using a JD-style day count. But ...

> Can TAI also be represented as an absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day?  If so, are there any specified rules for that?  (Conversion to or from that scale from either of the scales mentioned in the previous paragraph is a little more work, as you'd have to worry about month lengths and leap years).

I think that was probably ignored as an issue, since "everyone knows" how
the calendar works. The ISO 8601 rules for date sequences work perfectly
well and there's no reason to re-state them.

> And in what ways could the UTC scale be represented?  The "differs from it by an integral number of seconds", with the difference varying over time, would presumably be a difference between the "absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day" representations of TAI or UTC, given that "It corresponds exactly in rate with TAI" means that, for the "days, hours, minutes and seconds from the origin 1 January 1958" definition of TAI,

Okay so far.

> every one of those seconds occurs in UTC as well,

But some of them with an xx:xx:60 label (and, in theory, some xx:xx:59
labels missing).

> so if you represent UTC as a count of days, hours, minutes, and seconds from some origin, or just as a count of seconds from that origin, the difference between the two scales, in seconds, is the difference between the origins, in seconds.

I've always read it as the difference being the difference in broken-down
time labels (xx:xx:05 v xx:xx:41, or whatever) and *not* a difference in
seconds since some epoch.

> Annex 3 of that recommendation, "Dating of events in the vicinity of a leap-second", shows events being dated "30 June, 23h 59m 60.6s UTC"; as it's an example, the year is omitted, so presumably the "30 June" would have a year number after it for a real event, i.e. an absolute Gregorian-style date.

More evidence that they viewed the calendar bit was "well-known".

> > Me, I would say that (1) and (4) are completely compatible --
> > they're two different representations for the same underlying
> > time scale.  You can perfectly interconvert between them using
> > the same algorithm Posix defines for time_t.
> > 
> > When it comes to UTC, however, (2) and (3) are most definitely
> > not compatible.  Personally, I believe that (2) is the *only*
> > way to represent UTC.  I believe -- Posix time_t most assuredly
> > notwithstanding -- that (3) is an abomination.
> 
> (2) and (3) are both problematic.
> 
> With (2), time stamps for events defined to occur at a specified sufficiently large number of seconds in the future cannot be predicted.  That includes all events with times specified by a (1)-style or (4)-style time stamp if those times go past what the IERS has specified.

Of course. This is the basic "leap seconds problem".

> With (3), some time stamps cannot be specified - including time stamps for events in the *past*, such as an event occurring on 30 June 2015 at 23h 59m 60s UTC.

And that's the Posix problem.

[...]

> So if we want to describe *any* timekeeping scheme that represents times in a format that is, or can trivially be converted to and from without loss of information, a count of seconds, including leap seconds, since some epoch, as "TAI", OK.  That does *not*, of course, mean that the epoch needs to be expressed as a TAI time stamp; "seconds, including leap seconds, since 1970-01-01 00:00:00 UTC" would then be a representation of TAI (given that we know what instant of time was labeled 1970-01-01 00:00:00 UTC - no knowledge of the future is needed there).

Okay; I don't dispute that either.

Bluetooth Mesh used a TAI 00:00:00 epoch to simplify the conversion between
seconds-since-epoch and hh:mm:ss in people's minds. I accept that the only
difference between that and a UTC 00:00:00 epoch is a constant offset equal
to TAI-UTC at the moment of the epoch.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

From clive at davros.org  Mon Dec 16 16:27:50 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 16:27:50 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191216150712.GA8966@ucolick.org>
References: <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
 <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
 <20191216141021.GD490@davros.org>
 <20191216150712.GA8966@ucolick.org>
Message-ID: <20191216162750.GB97598@davros.org>

Steve Allen said:
> On Mon 2019-12-16T14:10:21+0000 Clive D.W. Feather hath writ:
> > You take a Gregorian calendar (by default; in principle you could use
> > Julian or something else) and use it to count *all* SI seconds, so that
> > every day has exactly 86400 seconds in it. It works the same way as UT1,
> > but without the unpredictable-length "seconds".
> 
> In 1968 between a pair of meetings the atomic clock and CCIR folks
> ascertained that they could not use that scheme in broadcast time
> signals,

*because* it drifts away from UT1, right? I'm not disputing that; I'm
simply saying that it works in the same way, just using real SI seconds
rather than sideral seconds.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

From missmistie27 at gmail.com  Mon Dec 16 17:39:54 2019
From: missmistie27 at gmail.com (Misty HICKMAN)
Date: Mon, 16 Dec 2019 11:39:54 -0600
Subject: [tz] (no subject)
Message-ID: <CAPLvikk9jfVYa5jM1cXQvCaCFmk-KKccMNRvHy3kJhk_K8vz6A@mail.gmail.com>

 Yes .   MistY       18months now .    Very clear     you know. The
cAlEndAr Y ear ?       Remember the TeaCUp ..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191216/82808396/attachment.html>

From Brian.Inglis at SystematicSw.ab.ca  Mon Dec 16 19:03:14 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Mon, 16 Dec 2019 12:03:14 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
Message-ID: <b026b59e-7c10-650a-00c3-d37aa4d3bfdb@SystematicSw.ab.ca>

On 2019-12-14 12:23, Guy Harris wrote:
> On Dec 14, 2019, at 8:00 AM, Steve Summit wrote:
>> Guy Harris wrote:
>>> On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather wrote:
>>>> Guy Harris said:

> ITU-R Recommendation TF.460-6 says:
> 
> 	2 Leap-seconds
> 
> 2.1 A positive or negative leap-second should be the last second of a UTC
> month, but first preference should be given to the end of December and June, and
> second preference to the end of March and September.
> 
> 2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the 
> first day of the following month. In the case of a negative leap-second, 23h
> 59m 58s will be followed one second later by 0h 0m 0s of the first day of
> the following month (see Annex 3).
> 
> but where 1) the form HHh Mmm SSs for time stamps specified for UTC, 2) is 
> that also specified for TAI?, 3) is it stated anywhere how days are indicated
> in this context (YYYY-MM-DD? DD MMMMM YYYY?)
> 
> What that Recommendation says is
> 
> B International atomic time (TAI)
> 
> The international reference scale of atomic time (TAI), based on the second 
> (SI), as realized on the rotating geoid, is formed by the BIPM on the basis
> of clock data supplied by cooperating establishments. It is in the form of a 
> continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 
> January 1958 (adopted by the CGPM 1971).
> 
> C Coordinated universal time (UTC)
> 
> UTC is the time-scale maintained by the BIPM, with assistance from the IERS, 
> which forms the basis of a coordinated dissemination of standard frequencies
> and time signals. It corresponds exactly in rate with TAI but differs from it
> by an integer number of seconds.
> 
> The UTC scale is adjusted by the insertion or deletion of seconds (positive 
> or negative leap-seconds) to ensure approximate agreement with UT1.
> 
> which, at most, says that, *for example*, TAI is in the form of days 
> (presumably days that are always exactly 86400 seconds long)), hours. 
> minutes, and seconds from "the origin 1 January 1958" (does that mean 
> "midnight, 1 January 1958"?).  If, in fact, "days" correspond to 
> exactly-86400-second-long days, and "the origin 1 January 1958" is
> "midnight, 1 January 1958", TAI could also be represented as a scale of
> seconds since the origin 1 January 1958, with conversion between those two
> scales being straightforward (division and remainder to go from the second
> scale to the first, multiplication and addition to go from the first scale to
> the second, given that there are no leap seconds, month lengths, or leap
> years to worry about).

Just to muddy things further, in an article in "Polar Motion: Historical and
Scientific Problems", ASP Conference Series, Vol. 208, also IAU Colloquium #178.
Edited by Steven Dick, Dennis McCarthy, and Brian Luzum. (San Francisco: ASP)
ISBN: 1-58381-039-0, 2000., "History of the Bureau International de l'Heure",
Guinot, B., p.181:

	http://articles.adsabs.harvard.edu/pdf/2000ASPC..208..175G#page=7

states in the third paragraph:

"By convention, all integrated atomic times, at BIH and elsewhere, were set so
that an event at 1958 January 1, 0h UT2, receive the same date in UT2 and atomic
time scales. However, the observatories used their own values of UT2: that
explains that longitude errors of a few 0.01s appear in the local independent
time scales, as they are presently realized."

Reading that page and the next, it is apparent that AT, AM, A3, TA, TAI
frequencies have been tweaked and steered to maintain consistency with earlier
timescales and standards as well as between organizations. See also:

	https://www.ucolick.org/~sla/leapsecs/taiepoch.html

and linked Bulletin Horaire scans, also:

	https://www.bipm.org/en/bipm-services/timescales/tai.html

"The long-term stability of TAI is assured by weighting the participating
clocks. The scale unit of TAI is kept as close as possible to the SI second by
using data from those national laboratories which maintain the best primary
caesium standards."

so all should bear in mind that TAI is a synthetic timescale calculated and
adjusted in arrears, so shares some of the same problems as leap seconds but
occurring at higher precisions.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

From michael.h.deckers at googlemail.com  Mon Dec 16 21:11:59 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Mon, 16 Dec 2019 21:11:59 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <b026b59e-7c10-650a-00c3-d37aa4d3bfdb@SystematicSw.ab.ca>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <b026b59e-7c10-650a-00c3-d37aa4d3bfdb@SystematicSw.ab.ca>
Message-ID: <3bd225aa-f496-0609-8e39-f1cafb1ab2d5@googlemail.com>


 ?? On 2019-12-16 19:03, Brian Inglis wrote:


> Just to muddy things further, in an article in "Polar Motion: Historical and
> Scientific Problems", ASP Conference Series, Vol. 208, also IAU Colloquium #178.
> Edited by Steven Dick, Dennis McCarthy, and Brian Luzum. (San Francisco: ASP)
> ISBN: 1-58381-039-0, 2000., "History of the Bureau International de l'Heure",
> Guinot, B., p.181:
>
> 	http://articles.adsabs.harvard.edu/pdf/2000ASPC..208..175G#page=7


 ?? Thanks for the reference!


> ...so all should bear in mind that TAI is a synthetic timescale calculated and
> adjusted in arrears, so shares some of the same problems as leap seconds but
> occurring at higher precisions.


 ?? "adjusted in arrears":
 ????? The definitive values of TAI are fixed about a month after the fact
 ????? (fast in astronomical terms!) by Circular T. A more uniform time 
scale
 ????? can be obtained when more than a month's future data are used; such
 ????? evaluations are done by the BIPM and published yearly as estimates
 ????? TT(BIPM xx) of TT.

 ?? "same problems as leap seconds":
 ????? I do not think so. That is, no astronomical observations (eg,
 ????? satellite orbits, pulsar timings) can currently reach or exceed
 ????? the accuracy of the determination of TT with earth-bound clocks,
 ????? and the upcoming use of optical clocks will lead to a significant
 ????? increase in accuracy. Nor is there any sign of a systematic
 ????? difference in rate between TAI and TT -- it would be "new physics",
 ????? I guess.

 ??? Michael Deckers.


From wyuenho at gmail.com  Thu Dec 19 11:26:40 2019
From: wyuenho at gmail.com (Jimmy Yuen Ho Wong)
Date: Thu, 19 Dec 2019 11:26:40 +0000
Subject: [tz] [PATCH] * asia: Correct Hong Kong section name.
Message-ID: <20191219112639.927-1-wyuenho@gmail.com>

There are no records of Hong Kong being referred to as Xianggang, in the past or
currently. The Pinyin romanization scheme of the Mandarin pronunciation of ??
is not officially recognized or even mentioned in official documents.

https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html

https://www.elegislation.gov.hk/hk/cap5
---
 asia | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/asia b/asia
index cca004f..4f19d14 100644
--- a/asia
+++ b/asia
@@ -572,7 +572,7 @@ Zone	Asia/Urumqi	5:50:20	-	LMT	1928
 			6:00	-	+06
 
 
-# Hong Kong (Xianggang)
+# Hong Kong
 
 # Milne gives 7:36:41.7; round this.
 
-- 
2.24.0


From eggert at cs.ucla.edu  Thu Dec 19 22:48:46 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Thu, 19 Dec 2019 14:48:46 -0800
Subject: [tz] [PATCH] * asia: Correct Hong Kong section name.
In-Reply-To: <20191219112639.927-1-wyuenho@gmail.com>
References: <20191219112639.927-1-wyuenho@gmail.com>
Message-ID: <176436bd-675d-f90d-4ef7-226bc3cd2d28@cs.ucla.edu>

Thanks, I installed that.

From wyuenho at gmail.com  Wed Dec 18 19:34:39 2019
From: wyuenho at gmail.com (Jimmy Yuen Ho Wong)
Date: Wed, 18 Dec 2019 19:34:39 +0000
Subject: [tz] [PATCH] * asia: Correct Hong Kong section name.
Message-ID: <20191218193438.99112-1-wyuenho@gmail.com>

There are no records of Hong Kong being referred to as Xianggang, in the past or
currently. The Pinyin romanization scheme of the Mandarin pronunciation of ??
is not officially recognized or even mentioned in official documents.

https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html

https://www.elegislation.gov.hk/hk/cap5
---
 asia | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/asia b/asia
index cca004f..4f19d14 100644
--- a/asia
+++ b/asia
@@ -572,7 +572,7 @@ Zone	Asia/Urumqi	5:50:20	-	LMT	1928
 			6:00	-	+06
 
 
-# Hong Kong (Xianggang)
+# Hong Kong
 
 # Milne gives 7:36:41.7; round this.
 
-- 
2.24.0


From arthurdavidolson at gmail.com  Tue Dec 24 21:14:26 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Tue, 24 Dec 2019 16:14:26 -0500
Subject: [tz] Timekeeping in the news
Message-ID: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>

"Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."

https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html

    @dashdashado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/a8d0e2ca/attachment.html>

From marshall.eubanks at gmail.com  Wed Dec 25 00:41:48 2019
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Tue, 24 Dec 2019 19:41:48 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
Message-ID: <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>

It was a time transfer error - the mission elapsed time clock was off
by 11 hours because it took the wrong time from the Atlas at
separation. They were very lucky not to lose the spacecraft.

https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/

Regards
Marshall Eubanks

On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
<arthurdavidolson at gmail.com> wrote:
>
> "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
>
> https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
>
>     @dashdashado

From alan.mintz at gmail.com  Wed Dec 25 01:46:46 2019
From: alan.mintz at gmail.com (Alan Mintz)
Date: Tue, 24 Dec 2019 17:46:46 -0800
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
Message-ID: <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>

Here's the NYT article that mentions the 11 hours:
https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an
interesting (though "armchair") analysis, noting that the mission countdown
started at T-11 hours:
https://forum.nasaspaceflight.com/index.php?topic=43958.860 .


On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <marshall.eubanks at gmail.com>
wrote:

> It was a time transfer error - the mission elapsed time clock was off
> by 11 hours because it took the wrong time from the Atlas at
> separation. They were very lucky not to lose the spacecraft.
>
>
> https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
>
> Regards
> Marshall Eubanks
>
> On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
> <arthurdavidolson at gmail.com> wrote:
> >
> > "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
> >
> > https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
> >
> >     @dashdashado
>


-- 
Alan Mintz <Alan.Mintz at gMail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/c9c63892/attachment.html>

From alan.mintz at gmail.com  Wed Dec 25 01:48:52 2019
From: alan.mintz at gmail.com (Alan Mintz)
Date: Tue, 24 Dec 2019 17:48:52 -0800
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
Message-ID: <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>

Oops. The correct NYT link for the 11 hours:
https://www.nytimes.com/2019/12/22/science/boeing-starliner-landing.html .

On Tue, Dec 24, 2019 at 5:46 PM Alan Mintz <alan.mintz at gmail.com> wrote:

> Here's the NYT article that mentions the 11 hours:
> https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an
> interesting (though "armchair") analysis, noting that the mission countdown
> started at T-11 hours:
> https://forum.nasaspaceflight.com/index.php?topic=43958.860 .
>
>
> On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <
> marshall.eubanks at gmail.com> wrote:
>
>> It was a time transfer error - the mission elapsed time clock was off
>> by 11 hours because it took the wrong time from the Atlas at
>> separation. They were very lucky not to lose the spacecraft.
>>
>>
>> https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
>>
>> Regards
>> Marshall Eubanks
>>
>> On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
>> <arthurdavidolson at gmail.com> wrote:
>> >
>> > "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
>> >
>> > https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
>> >
>> >     @dashdashado
>>
>
>
> --
> Alan Mintz <Alan.Mintz at gMail.com>
>


-- 
Alan Mintz <Alan.Mintz at gMail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/bab5ce49/attachment.html>

From howard.hinnant at gmail.com  Wed Dec 25 03:02:57 2019
From: howard.hinnant at gmail.com (Howard Hinnant)
Date: Tue, 24 Dec 2019 22:02:57 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
Message-ID: <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>

11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).  It would be great to know the facts...

Howard

On Dec 24, 2019, at 8:48 PM, Alan Mintz <alan.mintz at gmail.com> wrote:
> 
> Oops. The correct NYT link for the 11 hours: https://www.nytimes.com/2019/12/22/science/boeing-starliner-landing.html .
> 
> On Tue, Dec 24, 2019 at 5:46 PM Alan Mintz <alan.mintz at gmail.com> wrote:
> Here's the NYT article that mentions the 11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an interesting (though "armchair") analysis, noting that the mission countdown started at T-11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 .
> 
> 
> On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> It was a time transfer error - the mission elapsed time clock was off
> by 11 hours because it took the wrong time from the Atlas at
> separation. They were very lucky not to lose the spacecraft.
> 
> https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
> 
> Regards
> Marshall Eubanks
> 
> On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
> <arthurdavidolson at gmail.com> wrote:
> >
> > "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
> >
> > https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
> >
> >     @dashdashado
> 
> 
> --
> Alan Mintz <Alan.Mintz at gMail.com>
> 
> 
> --
> Alan Mintz <Alan.Mintz at gMail.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/4a1d7a55/signature.asc>

From marshall.eubanks at gmail.com  Wed Dec 25 03:11:23 2019
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Tue, 24 Dec 2019 22:11:23 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
Message-ID: <CAJNg7VJmkwuPiTqPrxkBn-nf_Cf3Q-KyU3J+FbM7DxgyFibpDQ@mail.gmail.com>

On Tue, Dec 24, 2019 at 10:03 PM Howard Hinnant
<howard.hinnant at gmail.com> wrote:
>
> 11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).

No, India is 5 hours and 30 minutes ahead of UTC and 10 hr 30 min
ahead of EST, and that half an hour does indeed matter.

Regards
Marshall

> It would be great to know the facts...
>
> Howard
>
> On Dec 24, 2019, at 8:48 PM, Alan Mintz <alan.mintz at gmail.com> wrote:
> >
> > Oops. The correct NYT link for the 11 hours: https://www.nytimes.com/2019/12/22/science/boeing-starliner-landing.html .
> >
> > On Tue, Dec 24, 2019 at 5:46 PM Alan Mintz <alan.mintz at gmail.com> wrote:
> > Here's the NYT article that mentions the 11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an interesting (though "armchair") analysis, noting that the mission countdown started at T-11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 .
> >
> >
> > On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> > It was a time transfer error - the mission elapsed time clock was off
> > by 11 hours because it took the wrong time from the Atlas at
> > separation. They were very lucky not to lose the spacecraft.
> >
> > https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
> >
> > Regards
> > Marshall Eubanks
> >
> > On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
> > <arthurdavidolson at gmail.com> wrote:
> > >
> > > "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
> > >
> > > https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
> > >
> > >     @dashdashado
> >
> >
> > --
> > Alan Mintz <Alan.Mintz at gMail.com>
> >
> >
> > --
> > Alan Mintz <Alan.Mintz at gMail.com>
>

From howard.hinnant at gmail.com  Wed Dec 25 03:26:37 2019
From: howard.hinnant at gmail.com (Howard Hinnant)
Date: Tue, 24 Dec 2019 22:26:37 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAJNg7VJmkwuPiTqPrxkBn-nf_Cf3Q-KyU3J+FbM7DxgyFibpDQ@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
 <CAJNg7VJmkwuPiTqPrxkBn-nf_Cf3Q-KyU3J+FbM7DxgyFibpDQ@mail.gmail.com>
Message-ID: <A1BA9855-9005-4F5C-A4EC-369F6B3C4085@gmail.com>

Ah, my mistake.  I missed the 30min, thanks.

Howard

On Dec 24, 2019, at 10:11 PM, Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> 
> On Tue, Dec 24, 2019 at 10:03 PM Howard Hinnant
> <howard.hinnant at gmail.com> wrote:
>> 
>> 11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).
> 
> No, India is 5 hours and 30 minutes ahead of UTC and 10 hr 30 min
> ahead of EST, and that half an hour does indeed matter.
> 
> Regards
> Marshall
> 
>> It would be great to know the facts...
>> 
>> Howard
>> 
>> On Dec 24, 2019, at 8:48 PM, Alan Mintz <alan.mintz at gmail.com> wrote:
>>> 
>>> Oops. The correct NYT link for the 11 hours: https://www.nytimes.com/2019/12/22/science/boeing-starliner-landing.html .
>>> 
>>> On Tue, Dec 24, 2019 at 5:46 PM Alan Mintz <alan.mintz at gmail.com> wrote:
>>> Here's the NYT article that mentions the 11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an interesting (though "armchair") analysis, noting that the mission countdown started at T-11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 .
>>> 
>>> 
>>> On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
>>> It was a time transfer error - the mission elapsed time clock was off
>>> by 11 hours because it took the wrong time from the Atlas at
>>> separation. They were very lucky not to lose the spacecraft.
>>> 
>>> https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
>>> 
>>> Regards
>>> Marshall Eubanks
>>> 
>>> On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
>>> <arthurdavidolson at gmail.com> wrote:
>>>> 
>>>> "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
>>>> 
>>>> https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
>>>> 
>>>>    @dashdashado
>>> 
>>> 
>>> --
>>> Alan Mintz <Alan.Mintz at gMail.com>
>>> 
>>> 
>>> --
>>> Alan Mintz <Alan.Mintz at gMail.com>
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/040147ac/signature.asc>

From tim at timtimeonline.com  Wed Dec 25 03:28:24 2019
From: tim at timtimeonline.com (Tim Parenti)
Date: Tue, 24 Dec 2019 22:28:24 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
Message-ID: <CAFpi07w0dxvbC_DknxvtNy7MF4qt7J603n6J80g13FBgG0aFog@mail.gmail.com>

On Tue, 24 Dec 2019 at 22:03, Howard Hinnant <howard.hinnant at gmail.com>
wrote:

> 11h...  Sure smells like a time zone issue.  Such as not taking time zones
> into account, or taking them into account incorrectly.  Fwiw, there?s an
> 11h difference between Cape Canaveral (launch site) and India (popular
> location for outsourced programming).


I have seen speculation on Twitter (unsubstantiated, of course) that it is
related to the difference between Cape Canaveral (currently UTC-5) and
the Baikonur Cosmodrome in Kazakhstan (UTC+6).  But anything of that sort
would of course raise the question of why *any* local time is being used
rather than UTC.

It would be great to know the facts...


Indeed.  I've only seen the phrase "11 hours" in reports, but of course, if
that's being used as an approximate figure rather than an exact one, there
could be any number of other possible causes.

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/d7584b32/attachment.html>

From PaulGBoulder at AIM.com  Wed Dec 25 04:37:01 2019
From: PaulGBoulder at AIM.com (Paul Gilmartin)
Date: Tue, 24 Dec 2019 21:37:01 -0700
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAFpi07w0dxvbC_DknxvtNy7MF4qt7J603n6J80g13FBgG0aFog@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
 <CAFpi07w0dxvbC_DknxvtNy7MF4qt7J603n6J80g13FBgG0aFog@mail.gmail.com>
Message-ID: <ED91395F-F1A8-4D50-BA97-FFED975AB159@AIM.com>

On 2019-12-24, at 20:28:24, Tim Parenti wrote:
> 
> On Tue, 24 Dec 2019 at 22:03, Howard Hinnant <howard.hinnant at gmail.com> wrote:
> 11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).
> 
> I have seen speculation on Twitter (unsubstantiated, of course) that it is related to the difference between Cape Canaveral (currently UTC-5) and the Baikonur Cosmodrome in Kazakhstan (UTC+6).  But anything of that sort would of course raise the question of why any local time is being used rather than UTC.
>  
One NASA convention is "Mission Elapsed Time":
    https://en.wikipedia.org/wiki/Mission_Elapsed_Time

... but they still have to get it right.

> It would be great to know the facts...
> 
> Indeed.  I've only seen the phrase "11 hours" in reports, but of course, if that's being used as an approximate figure rather than an exact one, there could be any number of other possible causes.
>  
In 1985 in Colorado, a fatal train wreck resulted from a scheduling error:
    https://www.ntsb.gov/investigations/AccidentReports/Pages/RAR8602.aspx

Speculation at the time, not confirmed in the NTSB report, was that one
train on Friday picked handwritten orders for Saturday.

-- gil


From Brian.Inglis at SystematicSw.ab.ca  Fri Dec 27 16:46:55 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Fri, 27 Dec 2019 09:46:55 -0700
Subject: [tz] Timekeeping in the news
In-Reply-To: <ED91395F-F1A8-4D50-BA97-FFED975AB159@AIM.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
 <CAFpi07w0dxvbC_DknxvtNy7MF4qt7J603n6J80g13FBgG0aFog@mail.gmail.com>
 <ED91395F-F1A8-4D50-BA97-FFED975AB159@AIM.com>
Message-ID: <1a68d51d-7298-c4a8-5584-794876d2aafe@SystematicSw.ab.ca>

On 2019-12-24 21:37, Paul Gilmartin via tz wrote:
> On 2019-12-24, at 20:28:24, Tim Parenti wrote:
>>
>> On Tue, 24 Dec 2019 at 22:03, Howard Hinnant <howard.hinnant at gmail.com> wrote:
>> 11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).
>>
>> I have seen speculation on Twitter (unsubstantiated, of course) that it is related to the difference between Cape Canaveral (currently UTC-5) and the Baikonur Cosmodrome in Kazakhstan (UTC+6).  But anything of that sort would of course raise the question of why any local time is being used rather than UTC.
>>  
> One NASA convention is "Mission Elapsed Time":
>     https://en.wikipedia.org/wiki/Mission_Elapsed_Time
> 
> ... but they still have to get it right.
> 
>> It would be great to know the facts...

...article has the added link:

https://www.nasaspaceflight.com/2019/12/oft-starliner-landing-white-sands/

linking to:

https://www.nasaspaceflight.com/2019/12/boeing-ula-momentous-starliner-uncrewed-test-flight/

https://www.nasaspaceflight.com/2019/12/starliner-mission-shortening-failure-successful-launch/

Some suggestion that powered up time was used and Centaur MET was *NOT* used!
If so that would raise the suspicion that perhaps a test configuration may not
have been reconfigured for flight.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

From lester at lsces.uk  Tue Dec 31 07:20:39 2019
From: lester at lsces.uk (Lester Caine)
Date: Tue, 31 Dec 2019 07:20:39 +0000
Subject: [tz] Fake UK news
Message-ID: <116b07e3-f60a-b28b-9d06-9f74a166e778@lsces.uk>

Or rather another proposal for changes to time zones that did not happen 
- SDST

https://www.bbc.co.uk/news/uk-50950961

-- 
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

From PaulGBoulder at AIM.com  Tue Dec 31 21:05:03 2019
From: PaulGBoulder at AIM.com (Paul Gilmartin)
Date: Tue, 31 Dec 2019 14:05:03 -0700
Subject: [tz] Hour 26?  (was: Chaning time zone for Unix based tasks)
References: <2EDF80BB-F614-456E-AEF2-1E1C22A6544A.ref@AIM.com>
Message-ID: <2EDF80BB-F614-456E-AEF2-1E1C22A6544A@AIM.com>

(cross-posting to tz and IBM-MAIN)
Hi, TZData,

On a Linux system, I see:
1043 $ uname -a
Linux Bunsen5-PG 4.9.0-11-686-pae #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) i686 GNU/Linux
1044 $ cat /usr/share/zoneinfo/Asia/Tel_Aviv   | tail -1
IST-2IDT,M3.4.4/26,M10.5.0
1045 $ 

... This would seem to be Month 3, Week 4, Day 4, hour 26.
26?  Is that supposed to be 02:00 the next day?

But POSIX says:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08
... The hour shall be between zero and 24, and the minutes (and seconds)
-if present-between zero and 59. The result of using values outside 
of this range is unspecified.

z/OS (which supports only POSIX format) seems to ignore that TZ
(as allowed by "unspecified") and use UTC0:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/bpxa50065.htm
(It doesn't specify.)

Ouch!
-- gil


From eggert at cs.ucla.edu  Tue Dec 31 23:46:00 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Tue, 31 Dec 2019 15:46:00 -0800
Subject: [tz] Hour 26? (was: Chaning time zone for Unix based tasks)
In-Reply-To: <2EDF80BB-F614-456E-AEF2-1E1C22A6544A@AIM.com>
References: <2EDF80BB-F614-456E-AEF2-1E1C22A6544A.ref@AIM.com>
 <2EDF80BB-F614-456E-AEF2-1E1C22A6544A@AIM.com>
Message-ID: <34476839-faea-87e8-1933-67d1908787b9@cs.ucla.edu>

On 12/31/19 1:05 PM, Paul Gilmartin via tz wrote:

> 1044 $ cat /usr/share/zoneinfo/Asia/Tel_Aviv   | tail -1
> IST-2IDT,M3.4.4/26,M10.5.0
> 1045 $ 
> 
> ... This would seem to be Month 3, Week 4, Day 4, hour 26.
> 26?  Is that supposed to be 02:00 the next day?

Yes.

> POSIX says:

That's old news. Please see Internet RFC 8536 section 3.3.1 and
<http://austingroupbugs.net/view.php?id=1252>.

From arthurdavidolson at gmail.com  Sun Dec  1 19:34:26 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Sun, 1 Dec 2019 14:34:26 -0500
Subject: [tz] Addition to tz-art.html
Message-ID: <CAJvZEYmo4XhSPwa6cMvkijPYpTFKU0KEj0e-ReQFzV1ZVECqAw@mail.gmail.com>

This lament about the difficulty of time calculation peaked at number 7 on
the U. S. Billboard chart.

    @dashdashado

*** old/tz-art.html Sun Dec  1 14:12:32 2019
--- new/tz-art.html Sun Dec  1 14:28:34 2019
***************
*** 458,463 ****
--- 458,472 ----
  <tr><td><a href="
https://www.allmusic.com/album/youre-getting-better-the-word-jazz-dot-masters-mw0000736197">AMG
Rating</a></td><td>4.5 stars</td></tr>
  <tr><td>Notes</td><td>Includes the piece "What Time Is It"
  ("He knew what time it was everywhere...that counted").</td></tr>
+ <tr><td>&nbsp;</td><td></td></tr>
+ <tr><td>Artist</td><td>Chicago</td></tr>
+ <tr><td>CD</td><td>Chicago Transit Authority</td></tr>
+ <tr><td>Copyright Date</td><td>1969</td></tr>
+ <tr><td>Label</td><td>Columbia</td></tr>
+ <tr><td>ID</td><td>64409</td></tr>
+ <tr><td>Total Time</td><td>1:16:20</td></tr>
+ <tr><td><a href="
https://www.allmusic.com/album/chicago-transit-authority-mw0000189364">AMG
Rating</a></td><td>4 stars</td></tr>
+ <tr><td>Notes</td><td>Includes the song "Does Anybody Really Know What
Time It Is?"</td></tr>
  </table>
  <h2>Comics</h2>
  <ul>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191201/28f44985/attachment.htm>
-------------- next part --------------
*** old/tz-art.html	Sun Dec  1 14:12:32 2019
--- new/tz-art.html	Sun Dec  1 14:28:34 2019
***************
*** 458,463 ****
--- 458,472 ----
  <tr><td><a href="https://www.allmusic.com/album/youre-getting-better-the-word-jazz-dot-masters-mw0000736197">AMG Rating</a></td><td>4.5 stars</td></tr>
  <tr><td>Notes</td><td>Includes the piece "What Time Is It"
  ("He knew what time it was everywhere...that counted").</td></tr>
+ <tr><td>&nbsp;</td><td></td></tr>
+ <tr><td>Artist</td><td>Chicago</td></tr>
+ <tr><td>CD</td><td>Chicago Transit Authority</td></tr>
+ <tr><td>Copyright Date</td><td>1969</td></tr>
+ <tr><td>Label</td><td>Columbia</td></tr>
+ <tr><td>ID</td><td>64409</td></tr>
+ <tr><td>Total Time</td><td>1:16:20</td></tr>
+ <tr><td><a href="https://www.allmusic.com/album/chicago-transit-authority-mw0000189364">AMG Rating</a></td><td>4 stars</td></tr>
+ <tr><td>Notes</td><td>Includes the song "Does Anybody Really Know What Time It Is?"</td></tr>
  </table>
  <h2>Comics</h2>
  <ul>

From arthurdavidolson at gmail.com  Sun Dec  1 19:53:04 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Sun, 1 Dec 2019 14:53:04 -0500
Subject: [tz] tz-art.html playlist
Message-ID: <CAJvZEYm8Tka+VJUo-v3NdumxbHZiZZiYBaRhziLVgBe06Uhgmw@mail.gmail.com>

A playlist of 22 of the tunes noted in tz-art.html is now available at...
    https://open.spotify.com/playlist/681bJSY7FY7ppzLOcmYPdh

Nerdiest. Party. Ever.

    @dashdashado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191201/81ce0799/attachment.htm>

From skeet at pobox.com  Mon Dec  2 17:48:35 2019
From: skeet at pobox.com (Jon Skeet)
Date: Mon, 2 Dec 2019 17:48:35 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>

Could you clarify *exactly *how you derived your table, in terms of the
IANA data?

If you look at
https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul -
which is generated from IANA data - it shows DST changes stopping in
September 2016, just as you said.

Likewise if you look at the current source data
<https://github.com/eggert/tz/blob/1a27ec76bc436a64070461bbbf28e0511c7cf3b8/europe#L3889>,
you'll see the same result.

I suspect this is a problem of data interpretation rather than anything
else.

Jon


On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com>
wrote:

> Hello,
>
>
>
> I?d like to report your downloads for the following Time Zones from this
> URL on your site are out of date: https://www.iana.org/time-zones
>
>
>
> For instance Europe/Istanbul moved to UTC 3 permanently in September of
> 2016 and no longer follow DST.
>
>
>
> I will place the correct times first, and then the incorrect IANA times
> second. Highlighted in orange have the incorrect time zone information (0
> means there is no DST, 1 means they follow DST)
>
>
>
>
>
> TimeZone
>
> UTC Offset
>
> ObservesDST
>
> IANA_UTC_offset:
>
> IANA_ObservesDST:
>
> America/Campo_Grande
>
> -4
>
> 0
>
> -4
>
> 1
>
> America/Sao_Paulo
>
> -3
>
> 0
>
> -3
>
> 1
>
> America/St_Johns
>
> -3.5
>
> 1
>
> -3
>
> 1
>
> Asia/Sakhalin
>
> 11
>
> 0
>
> 10
>
> 0
>
> Australia/Adelaide
>
> 9.5
>
> 1
>
> 9
>
> 1
>
> Australia/Darwin
>
> 9.5
>
> 0
>
> 9
>
> 0
>
> Australia/Lord_Howe
>
> 10.5
>
> 1
>
> 10
>
> 1
>
> Europe/Istanbul
>
> 3
>
> 0
>
> 2
>
> 1
>
> Indian/Cocos
>
> 6.5
>
> 0
>
> 6
>
> 0
>
> Pacific/Chatham
>
> 12.75
>
> 1
>
> 12
>
> 1
>
>
>
> Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191202/e730a096/attachment.htm>

From Paul.Koning at dell.com  Mon Dec  2 17:52:28 2019
From: Paul.Koning at dell.com (Paul.Koning at dell.com)
Date: Mon, 2 Dec 2019 17:52:28 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <595268F5-0D29-484E-8279-1EE35BCF4A57@dell.com>

You may have broken tools.

The data looks correct to me.  For example, the Australia ones clearly have x:30 (half hour) offsets.  If you're not getting that, your parser and/or time formatting code may be defective.

paul


On Nov 25, 2019, at 8:04 PM, Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:


[EXTERNAL EMAIL]

Hello,

I?d like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones

For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST.

I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST)


TimeZone

UTC Offset

ObservesDST

IANA_UTC_offset:

IANA_ObservesDST:

America/Campo_Grande

-4

0

-4

1

America/Sao_Paulo

-3

0

-3

1

America/St_Johns

-3.5

1

-3

1

Asia/Sakhalin

11

0

10

0

Australia/Adelaide

9.5

1

9

1

Australia/Darwin

9.5

0

9

0

Australia/Lord_Howe

10.5

1

10

1

Europe/Istanbul

3

0

2

1

Indian/Cocos

6.5

0

6

0

Pacific/Chatham

12.75

1

12

1


Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191202/c7b9ed9d/attachment.htm>

From Benjamin.Weiser at inrix.com  Mon Dec  2 18:59:09 2019
From: Benjamin.Weiser at inrix.com (Benjamin Weiser)
Date: Mon, 2 Dec 2019 18:59:09 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
Message-ID: <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>

Thank you Jon,

I will have the dev take a look at why his tools are not refreshing the data correctly.  I do see the correct values in the links that you provided and in the download I mentioned. We were in the process of consolidating two teams that were sourcing TimeZones from different data sources. The team using IANA was claiming they were refreshing, so something must be going wrong with their tools as you suggested.

I appreciate the feedback.

From: Jon Skeet <skeet at pobox.com>
Sent: Monday, December 2, 2019 9:49 AM
To: Benjamin Weiser <Benjamin.Weiser at inrix.com>
Cc: tz at iana.org
Subject: Re: [tz] incorrect timezone info from tar files

Could you clarify exactly how you derived your table, in terms of the IANA data?

If you look at https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnodatime.org%2Ftzvalidate%2Fgenerate%3Fversion%3D2019c%26zone%3DEurope%2FIstanbul&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446283964&sdata=Z0%2Bx2yU00vEkAzTGo5Ur7NHttfjLRqsgX2y4E7j0dMg%3D&reserved=0> - which is generated from IANA data - it shows DST changes stopping in September 2016, just as you said.

Likewise if you look at the current source data<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feggert%2Ftz%2Fblob%2F1a27ec76bc436a64070461bbbf28e0511c7cf3b8%2Feurope%23L3889&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446288944&sdata=%2Bs4k7r5pNGwBw0lhOUEIcDYUrxWsKxdR2j5H7VWkXnI%3D&reserved=0>, you'll see the same result.

I suspect this is a problem of data interpretation rather than anything else.

Jon


On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:
Hello,

I?d like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Ftime-zones&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446293919&sdata=E4593Nqq4EaQadhjoAmDv7Ww9oy%2F2YcO7ByNps5SYA4%3D&reserved=0>

For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST.

I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST)


TimeZone
UTC Offset
ObservesDST
IANA_UTC_offset:
IANA_ObservesDST:
America/Campo_Grande
-4
0
-4
1
America/Sao_Paulo
-3
0
-3
1
America/St_Johns
-3.5
1
-3
1
Asia/Sakhalin
11
0
10
0
Australia/Adelaide
9.5
1
9
1
Australia/Darwin
9.5
0
9
0
Australia/Lord_Howe
10.5
1
10
1
Europe/Istanbul
3
0
2
1
Indian/Cocos
6.5
0
6
0
Pacific/Chatham
12.75
1
12
1

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191202/d5b40d16/attachment.htm>

From eggert at cs.ucla.edu  Mon Dec  2 19:31:45 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Mon, 2 Dec 2019 11:31:45 -0800
Subject: [tz] Unnecessary time zones in Ukraine territory
In-Reply-To: <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
Message-ID: <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>

On 11/26/19 6:04 AM, Mikhail Gribanov wrote:

>> Europe/Uzhgorod
>> Europe/Zaporozhye
>>
>> Can you explain why they were added? I did not find any evidence of
>> the existence of events "Ruthenia used CET 1990/1991" (comment in tz
>> database).

As I recall, they were added because Shanks's International Atlas had 
them. The "europe" file says:

# Unless otherwise specified, the source for data through 1990 is:
# Thomas G. Shanks and Rique Pottenger, The International Atlas (6th 
edition),
# San Diego: ACS Publications, Inc. (2003).
# Unfortunately this book contains many errors and cites no sources.

It's quite possible that Shanks was wrong, or that I transcribed Shanks 
incorrectly. If so, it'd be helpful to provide evidence of the error, so 
that we can fix tzdb.


From eggert at cs.ucla.edu  Mon Dec  2 19:41:38 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Mon, 2 Dec 2019 11:41:38 -0800
Subject: [tz] Help on Updating Java Time ZOne
In-Reply-To: <VI1PR06MB4029D9840DF78457854495E49D470@VI1PR06MB4029.eurprd06.prod.outlook.com>
References: <VI1PR06MB4029D9840DF78457854495E49D470@VI1PR06MB4029.eurprd06.prod.outlook.com>
Message-ID: <84250fe1-e420-80a8-e655-69486e324a3f@cs.ucla.edu>

On 11/28/19 11:26 AM, Santos, Cosme wrote:

>  ??????????????? What is tzcode and tzdb, should I update them to?

Please see <https://data.iana.org/time-zones/tz-link.html> for more 
about tzcode and tzdb. If your application uses routines not written in 
Java, you'll also need to update your operating system's time zone 
tables; details depend on the OS.

>  ??????????????? Also, the Brazil Timezone change, 2019 we won?t have 
> it, so a friend sent me the tzdata2019c-rearguard.tar.gz (is this a good 
> file?)

That depends on your friend. You can generate your own 
tzdata2019c-rearguard.tar.gz file by following the instructions in the 
main tzdb distribution.

If your problem is purely Java-related, you might have better luck 
updating to a more-recent Java release. If you're using Oracle Java, 
<https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html> 
suggests that you run 7u241, 8u231, 11.0.50, 13.0.1, or later.


From eggert at cs.ucla.edu  Tue Dec  3 02:28:56 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Mon, 2 Dec 2019 18:28:56 -0800
Subject: [tz] USG_COMPAT and POSIX and XOPEN macros
In-Reply-To: <CAA0nTRuwpznqTJcZZ3Kfa=r-Dkh1zfdzLcga_f7gfn2PDzvuQw@mail.gmail.com>
References: <CAA0nTRtKgsvV8YDwaKNqwCjOX-teqW5aXEJZeQW-NVt7iNgA7A@mail.gmail.com>
 <27723656-ee4b-7523-12e0-55f1c484240d@cs.ucla.edu>
 <CAA0nTRvCPkPHCOH71FC_eX9rXAhb3eY+qGDynzqtW4CAhTrNLA@mail.gmail.com>
 <138de0a4-2e9a-4f96-931e-397fa54ff8b3@cs.ucla.edu>
 <CAA0nTRuwpznqTJcZZ3Kfa=r-Dkh1zfdzLcga_f7gfn2PDzvuQw@mail.gmail.com>
Message-ID: <c6c65e37-a17b-010e-49a5-65c3f1989d79@cs.ucla.edu>

On 11/30/19 7:31 AM, Andras Farkas wrote:
> On Fri, Nov 29, 2019 at 2:55 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> However, on FreeBSD (thinking back to the connections between this
> thread and another thread) compilation fails with:
> CFLAGS= -DUSG_COMPAT=2 -DHAVE_POSIX_DECLS=0
> I suggest something like the attached diff, which makes compilation
> succeed, while fitting in line with what the internal macros are
> currently doing.

Thanks for the bug report. Unfortunately that patch would refer to 
TZ_TIME_T before it's defined, and TZ_TIME_T's definition depends on 
time.h which must be included after the first part of the patch. So I 
installed the attached patch, which does not refer to TZ_TIME_H and 
which I hope fixes the problem in a simpler way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-DUSG_COMPAT-2-on-FreeBSD.patch
Type: text/x-patch
Size: 1445 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20191202/fa1cac40/attachment.bin>

From eggert at cs.ucla.edu  Tue Dec  3 02:40:08 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Mon, 2 Dec 2019 18:40:08 -0800
Subject: [tz] Addition to tz-art.html
In-Reply-To: <CAJvZEYmo4XhSPwa6cMvkijPYpTFKU0KEj0e-ReQFzV1ZVECqAw@mail.gmail.com>
References: <CAJvZEYmo4XhSPwa6cMvkijPYpTFKU0KEj0e-ReQFzV1ZVECqAw@mail.gmail.com>
Message-ID: <bfc8e462-5dd9-9fb6-69c0-fce008f792dc@cs.ucla.edu>

Thanks, I installed that.


From deepbluemistake at gmail.com  Tue Dec  3 02:57:27 2019
From: deepbluemistake at gmail.com (Andras Farkas)
Date: Mon, 2 Dec 2019 21:57:27 -0500
Subject: [tz] USG_COMPAT and POSIX and XOPEN macros
In-Reply-To: <c6c65e37-a17b-010e-49a5-65c3f1989d79@cs.ucla.edu>
References: <CAA0nTRtKgsvV8YDwaKNqwCjOX-teqW5aXEJZeQW-NVt7iNgA7A@mail.gmail.com>
 <27723656-ee4b-7523-12e0-55f1c484240d@cs.ucla.edu>
 <CAA0nTRvCPkPHCOH71FC_eX9rXAhb3eY+qGDynzqtW4CAhTrNLA@mail.gmail.com>
 <138de0a4-2e9a-4f96-931e-397fa54ff8b3@cs.ucla.edu>
 <CAA0nTRuwpznqTJcZZ3Kfa=r-Dkh1zfdzLcga_f7gfn2PDzvuQw@mail.gmail.com>
 <c6c65e37-a17b-010e-49a5-65c3f1989d79@cs.ucla.edu>
Message-ID: <CAA0nTRuywSs+BZEHQ6Bm_+Vb8Sei7furz-A60xEfcBkOVdgPhg@mail.gmail.com>

On Mon, Dec 2, 2019 at 9:28 PM Paul Eggert <eggert at cs.ucla.edu> wrote:
> Thanks for the bug report. Unfortunately that patch would refer to
> TZ_TIME_T before it's defined, and TZ_TIME_T's definition depends on
> time.h which must be included after the first part of the patch. So I
Oh!  Good point.
> installed the attached patch, which does not refer to TZ_TIME_H and
> which I hope fixes the problem in a simpler way.
This looks good and runs perfectly.
Both
CFLAGS= -DUSG_COMPAT=2
CFLAGS= -DUSG_COMPAT=2 -DHAVE_POSIX_DECLS=0
work A-OK now!
Thanks! :D


From alois at astro.ch  Tue Dec  3 11:11:53 2019
From: alois at astro.ch (Alois Treindl)
Date: Tue, 3 Dec 2019 12:11:53 +0100
Subject: [tz] Unnecessary time zones in Ukraine territory?
In-Reply-To: <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
Message-ID: <07bc0b5a-a7ef-d17f-29e9-c511004ca58f@astro.ch>

An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/ac66dc8d/attachment.htm>

From alois at astro.ch  Tue Dec  3 12:38:56 2019
From: alois at astro.ch (Alois Treindl)
Date: Tue, 3 Dec 2019 13:38:56 +0100
Subject: [tz] Unnecessary time zones in Ukraine territory?
In-Reply-To: <07bc0b5a-a7ef-d17f-29e9-c511004ca58f@astro.ch>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
 <07bc0b5a-a7ef-d17f-29e9-c511004ca58f@astro.ch>
Message-ID: <de90982a-5583-959b-184c-8f597bd07c81@astro.ch>

An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/d6ff4cf1/attachment.htm>

From alois at astro.ch  Tue Dec  3 12:58:14 2019
From: alois at astro.ch (Alois Treindl)
Date: Tue, 3 Dec 2019 13:58:14 +0100
Subject: [tz] Unnecessary time zones in Ukraine territory?
In-Reply-To: <de90982a-5583-959b-184c-8f597bd07c81@astro.ch>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
 <07bc0b5a-a7ef-d17f-29e9-c511004ca58f@astro.ch>
 <de90982a-5583-959b-184c-8f597bd07c81@astro.ch>
Message-ID: <7840e11b-ab06-986d-85bc-dfe2005f65ff@astro.ch>

An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/96538aef/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ciekhhicmonlbejg.png
Type: image/png
Size: 138944 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/96538aef/attachment.png>

From Brian.Inglis at SystematicSw.ab.ca  Tue Dec  3 20:20:09 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Tue, 3 Dec 2019 13:20:09 -0700
Subject: [tz] Help on Updating Java Time Zone
In-Reply-To: <84250fe1-e420-80a8-e655-69486e324a3f@cs.ucla.edu>
References: <VI1PR06MB4029D9840DF78457854495E49D470@VI1PR06MB4029.eurprd06.prod.outlook.com>
 <84250fe1-e420-80a8-e655-69486e324a3f@cs.ucla.edu>
Message-ID: <879a93ff-9a38-19ce-59e3-be6d975ab6d8@SystematicSw.ab.ca>


On 2019-12-02 12:41, Paul Eggert wrote:
> On 11/28/19 11:26 AM, Santos, Cosme wrote:
>> What is tzcode and tzdb, should I update them to?
> Please see <https://data.iana.org/time-zones/tz-link.html> for more about tzcode
> and tzdb. If your application uses routines not written in Java, you'll also
> need to update your operating system's time zone tables; details depend on the OS.

...and JDKs, Java Libraries, and JVMs: GNU Classpath, Google/Android/Dalvik,
IBM/Eclipse/OpenJ9, OpenJDK, Oracle/SUN, IKVM, JAM, Jikes, Kaffe, Sable, etc.

It may perhaps be better to refer folks to their Java application, JDK, or JVM
provider for information about TZ updates.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


From Brian.Inglis at SystematicSw.ab.ca  Tue Dec  3 22:35:08 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Tue, 3 Dec 2019 15:35:08 -0700
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <e0613ed5-cbe0-489b-9b0b-16e182ca2b79@SystematicSw.ab.ca>

> On 2019-12-02 11:59, Benjamin Weiser wrote:
>> On Monday, December 2, 2019 9:49 AM, Jon Skeet wrote:
>>> On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser wrote:
>>>> I?d like to report your downloads for the following Time Zones from
>>>> this URL on your site are out of date: https://www.iana.org/time-zones>>>> For instance Europe/Istanbul moved to UTC 3 permanently in September of
>>>> 2016 and no longer follow DST.
>>>> I will place the correct times first, and then the incorrect IANA
>>>> times second. Highlighted in orange have the incorrect time zone
>>>> information (0 means there is no DST, 1 means they follow DST)

>>> Could you clarify /exactly /how you derived your table, in terms of the
>>> IANA data?
>>> If you look at 
>>> https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul
>>> - which is generated from IANA data - it shows DST changes stopping in
>>> September 2016, just as you said.
>>> Likewise if you look at the current source data, you'll see the same
>>> result.
>>> I suspect this is a problem of data interpretation rather than anything
>>> else.

>> I will have the dev take a look at why his tools are not refreshing the data
>> correctly. I do see the correct values in the links that you provided and in
>> the download I mentioned. We were in the process of consolidating two teams that
>> were sourcing TimeZones from different data sources. The team using IANA was
>> claiming they were refreshing, so something must be going wrong with their tools
>> as you suggested.

With a history of 215 code and 248 data releases over 27 years so far, with info
from hundreds of contributors across the globe every year, fed downstream to all
major systems, distros, vendors, orgs, projects, products, and languages,
feedback is similarly global, continuous, and timely; sometimes waiting weeks or
months for official government confirmation in announcements, decrees, laws,
orders, or regulations.

The list continually fields complaints that the data is out of date, when it is
the poster's systems, distros, vendors, orgs, projects, products, or languages
that are more likely to be out of date.
As this list and tzdb are one of the global sources for providing correct
localized date/time internationally, your other sources are most likely incorrect.
A simple search of the list archives would provide confirmation that the change

When applications are wrong, 90%+ of the time it is a specification or
implementation issue (and 90%+ of implementation issues are array or memory
access issues).
More likely your devs are trying to interpret the timezone data, rather than
just using it through the provided API, trying to be "efficient" or "smart",
rather than correct internationally.

The calendar, date/time, time zone/DST, locale, and internationalization APIs
are somewhat involved and unwieldy because people, languages, and countries are
inconsistent and difficult to deal with, especially if you want to do so correctly.

Treating date/time stamps and associated APIs as anything other than opaque
objects and methods leads to disaster, as we found during Y2K remediation.

In subsequent and current development, idiots still use two digit years and
non-standard opaque storage and I/O formats (anything other than mm/dd/yyyy in
US and yyyy-mm-dd everywhere; up to 2012 most others were uninterpretably
ambiguous during the first 12 days each month), pick apart dates, times,
subfields, try to convert them independently, and are surprised how often the
results are bad!

Developers should take whatever they have as a date/time stamp or string and
pass it through an opaque wrapper function, that calls all the standard API
functions in the required order, including any locale and internationalization
interpretations, to produce the complete desired result date/time stamp or
string. All other approaches are doomed to failure!

Many, often humorous, articles for developers have been written of the form: do
you know how many (one of:) seconds, minutes, hours, days, weeks, months, years,
centuries, millenia, are in (some larger measure of time), and the answers are
always as abstruse, obscure, and varied, as similar articles about how many
ounces were in bushels or barrels, when such units were in common use.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


From mikhail.gribanov at gmail.com  Tue Dec  3 09:14:39 2019
From: mikhail.gribanov at gmail.com (Mikhail Gribanov)
Date: Tue, 3 Dec 2019 11:14:39 +0200
Subject: [tz] Unnecessary time zones in Ukraine territory
In-Reply-To: <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
Message-ID: <CAAw3sASmzmcn2dfY1h3QDk1EYFkiWHUyt8jzbXYs4g8k7gS7dQ@mail.gmail.com>

Hello, thanks for reply!

There is only one time zone in Ukraine right now - Europe/Kiev (law
https://zakon.rada.gov.ua/laws/show/509-96-? paragraph 1, use Google
Translate). As for the others (Europe/Uzhgorod and Europe/Zaporozhye), I
could not find any information of them in the past. But maybe I was looking
badly, historical documents are harder to look for.

If possible, please mark these zones as inactive (if we assume that the
information in them is correct) or delete them (because they are useless
and nobody uses them). The main problem is that many third-party software
offers these zones to choose from. What is wrong because these zones do not
exist now.

PS: I am a citizen of Ukraine, so you can ask specific questions, I will
try to find answers to them. Unfortunately, I could not find Shanks's
International Atlas, therefore, I can?t verify the accuracy of the data.


??, 2 ???. 2019 ?. ? 21:31, Paul Eggert <eggert at cs.ucla.edu>:

> On 11/26/19 6:04 AM, Mikhail Gribanov wrote:
>
> >> Europe/Uzhgorod
> >> Europe/Zaporozhye
> >>
> >> Can you explain why they were added? I did not find any evidence of
> >> the existence of events "Ruthenia used CET 1990/1991" (comment in tz
> >> database).
>
> As I recall, they were added because Shanks's International Atlas had
> them. The "europe" file says:
>
> # Unless otherwise specified, the source for data through 1990 is:
> # Thomas G. Shanks and Rique Pottenger, The International Atlas (6th
> edition),
> # San Diego: ACS Publications, Inc. (2003).
> # Unfortunately this book contains many errors and cites no sources.
>
> It's quite possible that Shanks was wrong, or that I transcribed Shanks
> incorrectly. If so, it'd be helpful to provide evidence of the error, so
> that we can fix tzdb.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/8b76284a/attachment.htm>

From Scott.Nelson at thermeon.com  Tue Dec  3 20:36:31 2019
From: Scott.Nelson at thermeon.com (Scott Nelson)
Date: Tue, 3 Dec 2019 20:36:31 +0000
Subject: [tz] Howard Hinnant's Time Zone Database Parser
Message-ID: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>

I didn?t see a mention of Howard Hinnant?s Time Zone Database Parser (https://howardhinnant.github.io/date/tz.html); did I miss it or is it something worthwhile to add to your list on tz-link.html?
--
Scott






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/62a98e1c/attachment.htm>

From eggert at cs.ucla.edu  Tue Dec  3 23:09:41 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Tue, 3 Dec 2019 15:09:41 -0800
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
Message-ID: <91ffcc9a-f727-2efc-eb91-859604d11eeb@cs.ucla.edu>

On 12/3/19 12:36 PM, Scott Nelson wrote:
> I didn?t see a mention of Howard Hinnant?s Time Zone Database Parser 
> (https://howardhinnant.github.io/date/tz.html)

It's currently the 4th bullet in the "Other tz compilers" section:

https://data.iana.org/time-zones/tz-link.html#compilers


From arthurdavidolson at gmail.com  Tue Dec  3 23:12:14 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Tue, 3 Dec 2019 18:12:14 -0500
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
Message-ID: <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>

A passage from https://howardhinnant.github.io/date/tz.html that may bear
investigation appears below.

    @dashdashado

You can also customize the build by defining macros (e.g. on the command
line) as follows...

AUTO_DOWNLOAD

If AUTO_DOWNLOAD is 1 then first access to the timezone database will
install it if it hasn't been installed, and if it has, will use the remote
API to install the latest version if not already installed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/fdadd9bb/attachment.htm>

From eggert at cs.ucla.edu  Tue Dec  3 23:33:52 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Tue, 3 Dec 2019 15:33:52 -0800
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
 <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>
Message-ID: <d1962d35-5d33-d46f-cc46-650e923ace83@cs.ucla.edu>

On 12/3/19 3:12 PM, Arthur David Olson wrote:

>         If |AUTO_DOWNLOAD| is |1| then first access to the timezone
>         database will install it if it hasn't been installed, and if it
>         has, will use the remote API to install the latest version if
>         not already installed.

You're right, that's somewhat concerning, as iana.org is not set up to 
handle HTTPS requests from a lot of clients. Perhaps Howard can be 
talked into making his parser's default URL point somewhere else 
(GitHub?) instead of to iana.org. I'll CC: this message to him.

Also, although that parser scrapes the current version number from 
<https://www.iana.org/time-zones>, that web page's format is not 
standardized and might change. It would be more reliable to get the 
latest version number from 
<https://data.iana.org/time-zones/data/version>, or to get the latest 
version (including its version number) from 
<https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz>.


From howard.hinnant at gmail.com  Wed Dec  4 00:04:40 2019
From: howard.hinnant at gmail.com (Howard Hinnant)
Date: Tue, 3 Dec 2019 19:04:40 -0500
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <d1962d35-5d33-d46f-cc46-650e923ace83@cs.ucla.edu>
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
 <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>
 <d1962d35-5d33-d46f-cc46-650e923ace83@cs.ucla.edu>
Message-ID: <A58BD604-14F5-47FA-A620-8F548A16376F@gmail.com>

On Dec 3, 2019, at 6:33 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> 
> On 12/3/19 3:12 PM, Arthur David Olson wrote:
> 
>>        If |AUTO_DOWNLOAD| is |1| then first access to the timezone
>>        database will install it if it hasn't been installed, and if it
>>        has, will use the remote API to install the latest version if
>>        not already installed.
> 
> You're right, that's somewhat concerning, as iana.org is not set up to handle HTTPS requests from a lot of clients. Perhaps Howard can be talked into making his parser's default URL point somewhere else (GitHub?) instead of to iana.org. I'll CC: this message to him.
> 
> Also, although that parser scrapes the current version number from <https://www.iana.org/time-zones>, that web page's format is not standardized and might change. It would be more reliable to get the latest version number from <https://data.iana.org/time-zones/data/version>, or to get the latest version (including its version number) from <https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz>.

The end-game here is this library has been voted into the C++20 working draft, to be provided by the std::lib vendors.  And without the AUTO_DOWNLOAD feature.  Each platform will provide the database as Linux/Mac/BSD do now.

http://eel.is/c++draft/#time

As C++20 becomes more available, my library will be obsoleted by the std implementation.  It is a planned obsolesce.  The AUTO_DOWNLOAD will functionality will fade into the rearview mirror.

But do be aware that the IANA timezone database (not the tools) has now effectively become the provider for an ISO standard.  So try not to get too crazy with changing things. :-)

Howard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/tz/attachments/20191203/13b1ae49/attachment.sig>

From guy at alum.mit.edu  Wed Dec  4 00:09:47 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Tue, 3 Dec 2019 16:09:47 -0800
Subject: [tz] Unnecessary time zones in Ukraine territory
In-Reply-To: <CAAw3sASmzmcn2dfY1h3QDk1EYFkiWHUyt8jzbXYs4g8k7gS7dQ@mail.gmail.com>
References: <CAAw3sAT5-QHN0wJFYBBRn79jJBSg89Cfp9aUBYJJw+DgqcuW6g@mail.gmail.com>
 <CAAw3sATE8NJWXLUYLPzQYaAU9irwRKiB9O0h69fQm78AHNeEVg@mail.gmail.com>
 <be50faaf-905a-39ee-5b10-d573919f4d45@cs.ucla.edu>
 <CAAw3sASmzmcn2dfY1h3QDk1EYFkiWHUyt8jzbXYs4g8k7gS7dQ@mail.gmail.com>
Message-ID: <F9948B47-BF7A-4726-B519-233998E41DD9@alum.mit.edu>

On Dec 3, 2019, at 1:14 AM, Mikhail Gribanov <mikhail.gribanov at gmail.com> wrote:

> If possible, please mark these zones as inactive (if we assume that the information in them is correct) or delete them (because they are useless and nobody uses them).

To quote the tzdb's Theory file:

	ftp://ftp.iana.org/tz/tzdb-2018g/theory.html

"The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. It organizes time zone and daylight saving time data by partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch (1970-01-01 00:00:00 UTC). The database labels each timezone with a notable location and records all known clock transitions for that location. Although 1970 is a somewhat-arbitrary cutoff, there are significant challenges to moving the cutoff earlier even by a decade or two, due to the wide variety of local practices before computer timekeeping became prevalent.

Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone, because clocks in a timezone all agree after 1970 whereas a traditional time zone merely specifies current standard time. For example, applications that deal with current and future timestamps in the traditional North American mountain time zone can choose from the timezones America/Denver which observes US-style daylight saving time, America/Mazatlan which observes Mexican-style DST, and America/Phoenix which does not observe DST. Applications that also deal with past timestamps in the mountain time zone can choose from over a dozen timezones, such as America/Boise, America/Edmonton, and America/Hermosillo, each of which currently uses mountain time but differs from other timezones for some timestamps after 1970."

There's no notion of a zone being "inactive"; even if two different tzdb "timezones" (which I prefer to call "regions", so as not to confuse them with "traditional time zone[s]") now happen to be part of the same traditional time zone, that doesn't mean that one of them is now "inactive".

The tzdb does not exist only to allow converting the *current* time, expressed as some form of universal time (e.g., non-leap seconds that have elapsed since January 1, 1970, 00:00:00 UTC), to a local wall clock time; it also exists to convert times in the *past*:

	$ ls -l /System/Library/Kernels/kernel 
	-rwxr-xr-x  1 root  wheel  15867112 Oct 12 00:09 /System/Library/Kernels/kernel

to a wall-clock time.  The "somewhat-arbitrary" cutoff is the origin of time stamps on UN*X systems, as well as time_t in the Microsoft C library; a program storing times in that format could store a date/time going back that far, and might want to convert it to local time, so differences dating back that far could be useful (and we're not in a position to say confidently that they're not useful).

(And this is hardly unique to Ukraine - there are locations in the US that changed their "traditional time zone" in the 1990s.)

> The main problem is that many third-party software offers these zones to choose from. What is wrong because these zones do not exist now.

No, it's wrong because software shouldn't offer tzdb IDs to choose from.

If software can determine your location and find the appropriate tzdb ID for the location in a map, given the location, that's idea.  (The software running on my machine can do that - *and* if it sees that the machine has moved across tzdb ID boundaries, it updates the current local time zone setting; yes, it even does that in running processes that don't have TZ set explicitly.)

If not, then offering lists of cities, from which the user can select the nearest city, would work.

From fweimer at redhat.com  Wed Dec  4 10:25:29 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 04 Dec 2019 11:25:29 +0100
Subject: [tz] Howard Hinnant's Time Zone Database Parser
In-Reply-To: <A58BD604-14F5-47FA-A620-8F548A16376F@gmail.com> (Howard
 Hinnant's message of "Tue, 3 Dec 2019 19:04:40 -0500")
References: <9C95DC19-029C-42E6-965F-BE500B4E6A2F@thermeon.com>
 <CAJvZEYmaycHN4Q2MtzufGDfm7wSfNK+aFg5Kxah4cVc6XntrxA@mail.gmail.com>
 <d1962d35-5d33-d46f-cc46-650e923ace83@cs.ucla.edu>
 <A58BD604-14F5-47FA-A620-8F548A16376F@gmail.com>
Message-ID: <87wobcpeue.fsf@oldenburg2.str.redhat.com>

* Howard Hinnant:

> The end-game here is this library has been voted into the C++20
> working draft, to be provided by the std::lib vendors.  And without
> the AUTO_DOWNLOAD feature.  Each platform will provide the database as
> Linux/Mac/BSD do now.
>
> http://eel.is/c++draft/#time
>
> As C++20 becomes more available, my library will be obsoleted by the
> std implementation.  It is a planned obsolesce.  The AUTO_DOWNLOAD will
> functionality will fade into the rearview mirror.

I think I have commented on this before.

The API assumes that time zone have names that identify them, which is
generally not true.  On GNU/Linux, the system time zone is the tzdata
blob in /etc/localtime, and you cannot in general determine a name from
that.  Particularly not a name that you can use to set TZ and get back
the same blob or even the same time zone.  I suspect we could make up a
fake name like SYSTEM for this case.

It's not clear to me whether the expected implementation of the
time_zone * object returned from tzdb::current_zone() is one that
automatically reloads time zone information as it becomes available
(like the POSIX interfaces on GNU/Linux do).  In other words, there is
no need for reload_tzdb() to do anything in order to update the current
time zone data in a process.

The definition of struct tzdb with its public data members is really
strange.  Is it expected that in order to look up leap seconds,
applications look at leap vector?  Then it is impossible to implement
automatic reloading of leap seconds, which would be disappointing.

Thanks,
Florian



From skeet at pobox.com  Thu Dec  5 08:03:51 2019
From: skeet at pobox.com (Jon Skeet)
Date: Thu, 5 Dec 2019 08:03:51 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <CA+5fHtLueYNiJjxXdPq-7vJQwOS=EBFjEkBQMAYPOWptD0PK0g@mail.gmail.com>

On Thu, 5 Dec 2019 at 02:07, Benjamin Weiser <Benjamin.Weiser at inrix.com>
wrote:

> I do see a lot of these have recently updated.
>
>
>
> I still see an issue with Brazil. Are those to be assumed as updated as
> well? I?m still seeing, for example in America/Sao_Paulo:
>
>
>
> Zone America/Sao_Paulo             -3:06:28 -             LMT       1914
>
>                                                 -3:00      Brazil
> -03/-02 1963 Oct 23  0:00
>
>                                                 -3:00      1:00
> -02          1964
>
>                                                 -3:00      Brazil
> -03/-02
>
>
>
> The last line would indicate that its still following daylight savings,
> which Brazil scrapped this year.
>
>  -3:00     Brazil     -03/-02
>

No, that just means that since 1964, Sao_Paulo followed the Brazil rules.

The Brazil rules have no DST changes after 2019-02-17T02:00:00Z. See
https://nodatime.org/tzvalidate/generate?version=2019c&zone=America/Sao_Paulo

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191205/a17c0176/attachment.htm>

From eggert at cs.ucla.edu  Fri Dec  6 04:34:31 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Thu, 5 Dec 2019 20:34:31 -0800
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
Message-ID: <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>

On 12/4/19 1:04 PM, Michael Veth wrote:

> The NIST leapsecond bulletin includes an expiration time which serves to 
> indicate the maximum validity?interval for use of UTC time.? In order to 
> safely use UTC timestamps, the user needs to be aware of this maximum 
> validity time or they could be unknowingly introducing timing errors.
> 
> I was not able to find this field in the TZif (Feb 19) ICD.? Would it be 
> possible to add a field to the TZdb that would represent this expiration 
> time?

The TZif file format does provide for truncated files (see Internet RFC 
8536 section 5.1), and one can generate files truncated to the current 
UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this:

zic -r /@1593302427 -L leapseconds tzdata.zi

However, it's awkward that one must count the number of seconds since 
1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the 
numeric timestamp (1593302427 in this case) to pass to zic. We could add 
support to zic to do this sort of thing in a more-natural way.

A downside of the abovementioned approach is that it generates a TZif 
file that omits all DST and time zone transitions after the UTC 
expiration time. We could change the TZif format to represent UTC 
expiration time separately from the truncation time. One possibility 
would be to append a leap-second record with an "occur" value equal to 
the expiration time and a "corr" value equal to the previous record's 
"corr" value. Strictly speaking this would violate RFC 8536 section 3.2 
"leap-second records" - though I doubt whether many clients would care - 
and so I suppose we'd need to increment the TZif format version number 
from 3 to 4. On the other hand, any files generated by this method would 
continue to be "incorrect" in that they'd continue to predict timestamps 
past the maximum leap second validity, so perhaps it wouldn't be worth 
going to all this work to generate "incorrect" files.

I'll cc this to tz at iana.org and tzdist-bis at ietf.org to see whether 
anybody there cares to comment.


From arthurdavidolson at gmail.com  Fri Dec  6 05:09:46 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Fri, 6 Dec 2019 00:09:46 -0500
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
Message-ID: <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>

One odd possibility below.

    @dashdashado

Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28
                        0       -       POST

On Thu, Dec 5, 2019 at 11:34 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/4/19 1:04 PM, Michael Veth wrote:
>
> > The NIST leapsecond bulletin includes an expiration time which serves to
> > indicate the maximum validity interval for use of UTC time.  In order to
> > safely use UTC timestamps, the user needs to be aware of this maximum
> > validity time or they could be unknowingly introducing timing errors.
> >
> > I was not able to find this field in the TZif (Feb 19) ICD.  Would it be
> > possible to add a field to the TZdb that would represent this expiration
> > time?
>
> The TZif file format does provide for truncated files (see Internet RFC
> 8536 section 5.1), and one can generate files truncated to the current
> UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this:
>
> zic -r /@1593302427 -L leapseconds tzdata.zi
>
> However, it's awkward that one must count the number of seconds since
> 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the
> numeric timestamp (1593302427 in this case) to pass to zic. We could add
> support to zic to do this sort of thing in a more-natural way.
>
> A downside of the abovementioned approach is that it generates a TZif
> file that omits all DST and time zone transitions after the UTC
> expiration time. We could change the TZif format to represent UTC
> expiration time separately from the truncation time. One possibility
> would be to append a leap-second record with an "occur" value equal to
> the expiration time and a "corr" value equal to the previous record's
> "corr" value. Strictly speaking this would violate RFC 8536 section 3.2
> "leap-second records" - though I doubt whether many clients would care -
> and so I suppose we'd need to increment the TZif format version number
> from 3 to 4. On the other hand, any files generated by this method would
> continue to be "incorrect" in that they'd continue to predict timestamps
> past the maximum leap second validity, so perhaps it wouldn't be worth
> going to all this work to generate "incorrect" files.
>
> I'll cc this to tz at iana.org and tzdist-bis at ietf.org to see whether
> anybody there cares to comment.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191206/c28607d2/attachment.htm>

From michael.h.deckers at googlemail.com  Fri Dec  6 11:48:47 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Fri, 6 Dec 2019 11:48:47 +0000
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
 <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
Message-ID: <b83f4bde-dfa1-5434-c181-3384fdf73a1b@googlemail.com>


 ?? On 2019-12-06, Arthur David Olson proposed
 ?? a method to expose in TZif the expiration date
 ?? of the leap second information:


> One odd possibility below.
>
>      @dashdashado
>
> Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28
>                          0       -       POST
>


 ?? Why not produce a tzdb Zone for TAI? As if we had

 ?????? Zone??? Etc/TAI? 0:00:10 -????? TAI???? 1972 Jul? 1
 ??????????????????????? 0:00:11 -????? TAI???? 1973 Jan? 1
 ??????????????????????? ....
 ??????????????????????? 0:00:35 -????? TAI???? 2015 Jul? 1
 ??????????????????????? 0:00:36 -????? TAI???? 2017 Jan? 1
 ??????????????????????? 0:00:37 -????? TAI???? 2020 Jun 28
 ??????????????????????? 0:00:37 -????? N_A

 ?? After all, the Bulletins C of the IERS specify TAI as
 ?? a function of UTC, just like a tzdb "timezone".

 ?? Michael Deckers.



From Benjamin.Weiser at inrix.com  Thu Dec  5 02:07:14 2019
From: Benjamin.Weiser at inrix.com (Benjamin Weiser)
Date: Thu, 5 Dec 2019 02:07:14 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>

I do see a lot of these have recently updated.

I still see an issue with Brazil. Are those to be assumed as updated as well? I?m still seeing, for example in America/Sao_Paulo:

Zone America/Sao_Paulo             -3:06:28 -             LMT       1914
                                                -3:00      Brazil     -03/-02 1963 Oct 23  0:00
                                                -3:00      1:00        -02          1964
                                                -3:00      Brazil     -03/-02

The last line would indicate that its still following daylight savings, which Brazil scrapped this year.
 -3:00     Brazil     -03/-02

From: Benjamin Weiser
Sent: Monday, December 2, 2019 10:59 AM
To: Jon Skeet <skeet at pobox.com>
Cc: tz at iana.org
Subject: RE: [tz] incorrect timezone info from tar files

Thank you Jon,

I will have the dev take a look at why his tools are not refreshing the data correctly.  I do see the correct values in the links that you provided and in the download I mentioned. We were in the process of consolidating two teams that were sourcing TimeZones from different data sources. The team using IANA was claiming they were refreshing, so something must be going wrong with their tools as you suggested.

I appreciate the feedback.

From: Jon Skeet <skeet at pobox.com<mailto:skeet at pobox.com>>
Sent: Monday, December 2, 2019 9:49 AM
To: Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>>
Cc: tz at iana.org<mailto:tz at iana.org>
Subject: Re: [tz] incorrect timezone info from tar files

Could you clarify exactly how you derived your table, in terms of the IANA data?

If you look at https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnodatime.org%2Ftzvalidate%2Fgenerate%3Fversion%3D2019c%26zone%3DEurope%2FIstanbul&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446283964&sdata=Z0%2Bx2yU00vEkAzTGo5Ur7NHttfjLRqsgX2y4E7j0dMg%3D&reserved=0> - which is generated from IANA data - it shows DST changes stopping in September 2016, just as you said.

Likewise if you look at the current source data<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feggert%2Ftz%2Fblob%2F1a27ec76bc436a64070461bbbf28e0511c7cf3b8%2Feurope%23L3889&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446288944&sdata=%2Bs4k7r5pNGwBw0lhOUEIcDYUrxWsKxdR2j5H7VWkXnI%3D&reserved=0>, you'll see the same result.

I suspect this is a problem of data interpretation rather than anything else.

Jon


On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:
Hello,

I?d like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Ftime-zones&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446293919&sdata=E4593Nqq4EaQadhjoAmDv7Ww9oy%2F2YcO7ByNps5SYA4%3D&reserved=0>

For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST.

I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST)


TimeZone
UTC Offset
ObservesDST
IANA_UTC_offset:
IANA_ObservesDST:
America/Campo_Grande
-4
0
-4
1
America/Sao_Paulo
-3
0
-3
1
America/St_Johns
-3.5
1
-3
1
Asia/Sakhalin
11
0
10
0
Australia/Adelaide
9.5
1
9
1
Australia/Darwin
9.5
0
9
0
Australia/Lord_Howe
10.5
1
10
1
Europe/Istanbul
3
0
2
1
Indian/Cocos
6.5
0
6
0
Pacific/Chatham
12.75
1
12
1

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191205/526d8641/attachment.htm>

From webmaster at unitconverter.net  Fri Dec  6 05:27:49 2019
From: webmaster at unitconverter.net (LISA - Unit Converter)
Date: Fri, 6 Dec 2019 05:27:49 +0000
Subject: [tz] Link Suggestion for your Website Resources page
Message-ID: <1581552221.1077255.1575610057569@ip-10-1-0-82.ec2.internal>

Dear Webmaster,

As I?m sure you?re quite busy, I?ll be quick. I just check out your resource page https://data.iana.org/time-zones/code/tz-link.html. I love your posting. Great stuff!

I wanted to share some of my work with you. We have developed a site https://unitconverter.net/time-converter. Almost we cover all kinds of time conversion and calculation. I'm sure our tool is fit for your resource page.

I am hoping you will consider our tool, it will be a great appreciation for us.

Please add our tag as " Time Converter".

Feel free to reach out. And as always, I will continue to visit your website and stay current with your business. Also Please let me know if I can do anything in the future...

Kind Regards,

Lisa Grace.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191206/e507fa14/attachment.htm>

From steffen at sdaoden.eu  Fri Dec  6 17:35:30 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 06 Dec 2019 18:35:30 +0100
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <b83f4bde-dfa1-5434-c181-3384fdf73a1b@googlemail.com>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
 <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
 <b83f4bde-dfa1-5434-c181-3384fdf73a1b@googlemail.com>
Message-ID: <20191206173530.K2xlg%steffen@sdaoden.eu>

Michael H Deckers via tz wrote in <b83f4bde-dfa1-5434-c181-3384fdf73a1b@\
googlemail.com>:
 | ?? On 2019-12-06, Arthur David Olson proposed
 | ?? a method to expose in TZif the expiration date
 | ?? of the leap second information:
 |
 |> One odd possibility below.
 |>
 |>      @dashdashado
 |>
 |> Zone    Etc/Leapendstat 0       -       PRE     2020 Jun 28
 |>                          0       -       POST
 |>
 |
 | ?? Why not produce a tzdb Zone for TAI? As if we had
 |
 | ?????? Zone??? Etc/TAI? 0:00:10 -????? TAI???? 1972 Jul? 1
 | ??????????????????????? 0:00:11 -????? TAI???? 1973 Jan? 1
 | ??????????????????????? ....
 | ??????????????????????? 0:00:35 -????? TAI???? 2015 Jul? 1
 | ??????????????????????? 0:00:36 -????? TAI???? 2017 Jan? 1
 | ??????????????????????? 0:00:37 -????? TAI???? 2020 Jun 28
 | ??????????????????????? 0:00:37 -????? N_A
 |
 | ?? After all, the Bulletins C of the IERS specify TAI as
 | ?? a function of UTC, just like a tzdb "timezone".

That is a great idea!  What i always missed with UTC and leap
seconds, or say, time keeping as you get it on a Unix system out
of the box, is the difference to TAI, that is, the number of leap
seconds.  You could even do calendar stuff with seconds if you had
that possibility.  At least a bit.  But anyway it would be
possible to notify the occurrence of a leap second even after it
had happened, out of the box.
Interesting.  I never thought of that possibility.  It does not
seem to fit right/ ;).

 | ?? Michael Deckers.
 |
 --End of <b83f4bde-dfa1-5434-c181-3384fdf73a1b at googlemail.com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From madigo at gmail.com  Fri Dec  6 20:55:35 2019
From: madigo at gmail.com (=?UTF-8?Q?Rodrigo_Br=C3=BCning_Wessler?=)
Date: Fri, 6 Dec 2019 17:55:35 -0300
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>

Brazilian time zone rules was updated and released in version 2019b.

I'm using this version without issues.

On Fri, Dec 6, 2019 at 5:28 PM Benjamin Weiser <Benjamin.Weiser at inrix.com>
wrote:

> I do see a lot of these have recently updated.
>
>
>
> I still see an issue with Brazil. Are those to be assumed as updated as
> well? I?m still seeing, for example in America/Sao_Paulo:
>
>
>
> Zone America/Sao_Paulo             -3:06:28 -             LMT       1914
>
>                                                 -3:00      Brazil
> -03/-02 1963 Oct 23  0:00
>
>                                                 -3:00      1:00
> -02          1964
>
>                                                 -3:00      Brazil
> -03/-02
>
>
>
> The last line would indicate that its still following daylight savings,
> which Brazil scrapped this year.
>
>  -3:00     Brazil     -03/-02
>
>
>
> *From:* Benjamin Weiser
> *Sent:* Monday, December 2, 2019 10:59 AM
> *To:* Jon Skeet <skeet at pobox.com>
> *Cc:* tz at iana.org
> *Subject:* RE: [tz] incorrect timezone info from tar files
>
>
>
> Thank you Jon,
>
>
>
> I will have the dev take a look at why his tools are not refreshing the
> data correctly.  I do see the correct values in the links that you provided
> and in the download I mentioned. We were in the process of consolidating
> two teams that were sourcing TimeZones from different data sources. The
> team using IANA was claiming they were refreshing, so something must be
> going wrong with their tools as you suggested.
>
>
>
> I appreciate the feedback.
>
>
>
> *From:* Jon Skeet <skeet at pobox.com>
> *Sent:* Monday, December 2, 2019 9:49 AM
> *To:* Benjamin Weiser <Benjamin.Weiser at inrix.com>
> *Cc:* tz at iana.org
> *Subject:* Re: [tz] incorrect timezone info from tar files
>
>
>
> Could you clarify *exactly *how you derived your table, in terms of the
> IANA data?
>
>
>
> If you look at
> https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnodatime.org%2Ftzvalidate%2Fgenerate%3Fversion%3D2019c%26zone%3DEurope%2FIstanbul&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446283964&sdata=Z0%2Bx2yU00vEkAzTGo5Ur7NHttfjLRqsgX2y4E7j0dMg%3D&reserved=0> -
> which is generated from IANA data - it shows DST changes stopping in
> September 2016, just as you said.
>
>
>
> Likewise if you look at the current source data
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feggert%2Ftz%2Fblob%2F1a27ec76bc436a64070461bbbf28e0511c7cf3b8%2Feurope%23L3889&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446288944&sdata=%2Bs4k7r5pNGwBw0lhOUEIcDYUrxWsKxdR2j5H7VWkXnI%3D&reserved=0>,
> you'll see the same result.
>
>
>
> I suspect this is a problem of data interpretation rather than anything
> else.
>
>
>
> Jon
>
>
>
>
>
> On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com>
> wrote:
>
> Hello,
>
>
>
> I?d like to report your downloads for the following Time Zones from this
> URL on your site are out of date: https://www.iana.org/time-zones
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Ftime-zones&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7Cd01d518b278744bee4b708d7774feb5b%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C1%7C637109057446293919&sdata=E4593Nqq4EaQadhjoAmDv7Ww9oy%2F2YcO7ByNps5SYA4%3D&reserved=0>
>
>
>
> For instance Europe/Istanbul moved to UTC 3 permanently in September of
> 2016 and no longer follow DST.
>
>
>
> I will place the correct times first, and then the incorrect IANA times
> second. Highlighted in orange have the incorrect time zone information (0
> means there is no DST, 1 means they follow DST)
>
>
>
>
>
> TimeZone
>
> UTC Offset
>
> ObservesDST
>
> IANA_UTC_offset:
>
> IANA_ObservesDST:
>
> America/Campo_Grande
>
> -4
>
> 0
>
> -4
>
> 1
>
> America/Sao_Paulo
>
> -3
>
> 0
>
> -3
>
> 1
>
> America/St_Johns
>
> -3.5
>
> 1
>
> -3
>
> 1
>
> Asia/Sakhalin
>
> 11
>
> 0
>
> 10
>
> 0
>
> Australia/Adelaide
>
> 9.5
>
> 1
>
> 9
>
> 1
>
> Australia/Darwin
>
> 9.5
>
> 0
>
> 9
>
> 0
>
> Australia/Lord_Howe
>
> 10.5
>
> 1
>
> 10
>
> 1
>
> Europe/Istanbul
>
> 3
>
> 0
>
> 2
>
> 1
>
> Indian/Cocos
>
> 6.5
>
> 0
>
> 6
>
> 0
>
> Pacific/Chatham
>
> 12.75
>
> 1
>
> 12
>
> 1
>
>
>
> Thanks.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191206/895e3822/attachment.htm>

From guy at alum.mit.edu  Fri Dec  6 21:44:26 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Fri, 6 Dec 2019 13:44:26 -0800
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
Message-ID: <5AB28AAF-23B4-4557-B642-0218B51FBAB2@alum.mit.edu>

On Dec 4, 2019, at 6:07 PM, Benjamin Weiser <Benjamin.Weiser at inrix.com> wrote:

> I still see an issue with Brazil. Are those to be assumed as updated as well? I?m still seeing, for example in America/Sao_Paulo:
> 
>  
> 
> Zone America/Sao_Paulo             -3:06:28   -          LMT       1914
>                                    -3:00      Brazil     -03/-02   1963 Oct 23  0:00
>                                    -3:00      1:00       -02       1964
>                                    -3:00      Brazil     -03/-02
> 
> The last line would indicate that its still following daylight savings, which Brazil scrapped this year.

No, it doesn't.  It says that it's following the "Brazil" rules, which are, in the 2019b and 2019c releases:

	...

Rule	Brazil	2008	2017	-	Oct	Sun>=15	0:00	1:00	-
Rule	Brazil	2008	2011	-	Feb	Sun>=15	0:00	0	-
Rule	Brazil	2012	only	-	Feb	Sun>=22	0:00	0	-
Rule	Brazil	2013	2014	-	Feb	Sun>=15	0:00	0	-
Rule	Brazil	2015	only	-	Feb	Sun>=22	0:00	0	-
Rule	Brazil	2016	2019	-	Feb	Sun>=15	0:00	0	-
Rule	Brazil	2018	only	-	Nov	Sun>=1	0:00	1:00	-

which says that (among other things, but I omitted the earlier rules that go back to 1931):

	on the third Sunday in October 2008-2017, the clocks are set forward to 1 hour ahead of standard time;

	on the third Sunday in February 2008-2011, the clocks are set backward to standard time;

	on the fourth Sunday in February 2012, the clocks are set backward to standard time;

	on the third Sunday in February 2013-2014, the clocks are set backward to standard time;

	on the fourth Sunday in February 2015, the clocks are set to standard time;

	on the third Sunday in February 2016-2019, the clocks are set to standard time;

	on the first Sunday in November 2018, the clocks are set forward to 1 hour ahead of standard time;

so they got set to standard time on 2019-02-17 and have not been set forward since - in particular, they were not set forward in November.

From eggert at cs.ucla.edu  Fri Dec  6 21:45:22 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Fri, 6 Dec 2019 13:45:22 -0800
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
 <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
Message-ID: <5397b1f1-7db6-e190-f978-4f8dda59d67f@cs.ucla.edu>

On 12/5/19 9:09 PM, Arthur David Olson wrote:

> Zone ? ?Etc/Leapendstat 0 ? ? ? - ? ? ? PRE ? ? 2020 Jun 28
>  ? ? ? ? ? ? ? ? ? ? ? ? 0 ? ? ? - ? ? ? POST

Although that would let someone determine leap second validity by 
examining a different file (or issuing another TZDIST request), Michael 
Veth was asking for a way to determine leap second validity by examining 
the same TZif file that contains the leap-second records.

On 12/6/19 3:48 AM, Michael H Deckers wrote:

>    Why not produce a tzdb Zone for TAI? As if we had
> 
>        Zone    Etc/TAI  0:00:10 -      TAI     1972 Jul  1
>                         0:00:11 -      TAI     1973 Jan  1
>                         ....
>                         0:00:35 -      TAI     2015 Jul  1
>                         0:00:36 -      TAI     2017 Jan  1
>                         0:00:37 -      TAI     2020 Jun 28
>                         0:00:37 -      N_A 

This won't have the desired effect. For example, it would cause the 
Etc/TAI clock's adjacent ticks to be 1972-06-30 23:59:59 and 1972-07-01 
00:00:01, whereas the adjacent ticks should be 1972-06-30 23:59:60 and 
1972-07-01 00:00:00. Also, when compiling the Etc/TAI zone with -L 
leapseconds, the resulting TZif file would have incorrect transitions 
because each leap second would be applied twice.


From mj1856 at hotmail.com  Sat Dec  7 01:12:34 2019
From: mj1856 at hotmail.com (Matt Johnson-Pint)
Date: Sat, 7 Dec 2019 01:12:34 +0000
Subject: [tz] Link Suggestion for your Website Resources page
In-Reply-To: <1581552221.1077255.1575610057569@ip-10-1-0-82.ec2.internal>
References: <1581552221.1077255.1575610057569@ip-10-1-0-82.ec2.internal>
Message-ID: <BYAPR06MB3879F72F027C338B6464B33DC25E0@BYAPR06MB3879.namprd06.prod.outlook.com>

How do I downvote here?
________________________________
From: tz <tz-bounces at iana.org> on behalf of LISA - Unit Converter <webmaster at unitconverter.net>
Sent: Friday, December 6, 2019 6:27:49 AM
To: tz at iana.org <tz at iana.org>
Subject: [tz] Link Suggestion for your Website Resources page


Dear Webmaster,

As I?m sure you?re quite busy, I?ll be quick. I just check out your resource page https://data.iana.org/time-zones/code/tz-link.html. I love your posting. Great stuff!

I wanted to share some of my work with you. We have developed a site https://unitconverter.net/time-converter. Almost we cover all kinds of time conversion and calculation. I'm sure our tool is fit for your resource page.

I am hoping you will consider our tool, it will be a great appreciation for us.

Please add our tag as " Time Converter".

Feel free to reach out. And as always, I will continue to visit your website and stay current with your business. Also Please let me know if I can do anything in the future...

Kind Regards,

Lisa Grace.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191207/bf147951/attachment.htm>

From michael.h.deckers at googlemail.com  Sat Dec  7 01:15:26 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Sat, 7 Dec 2019 01:15:26 +0000
Subject: [tz] Leap Second Support Interval Field Request - RFC8536
In-Reply-To: <5397b1f1-7db6-e190-f978-4f8dda59d67f@cs.ucla.edu>
References: <CAM6iTuYo8wPk88XiNhiPF1_7oHEkRUpyiwJa8-g8E9teR9cZcw@mail.gmail.com>
 <07ffd02d-ab8b-4d9f-ab27-dd6b0691e039@cs.ucla.edu>
 <CAJvZEYkWdUoKyLgeQVX5=o63L3wm0pu+B6siaR+GXQzpePA_zg@mail.gmail.com>
 <5397b1f1-7db6-e190-f978-4f8dda59d67f@cs.ucla.edu>
Message-ID: <c85e1997-2177-1b79-b400-b73037d338f7@googlemail.com>


On 2019-12-06 21:45, Paul Eggert wrote:

> This won't have the desired effect. For example, it would cause the 
> Etc/TAI clock's adjacent ticks to be 1972-06-30 23:59:59 and 
> 1972-07-01 00:00:01, whereas the adjacent ticks should be 1972-06-30 
> 23:59:60 and 1972-07-01 00:00:00. Also, when compiling the Etc/TAI 
> zone with -L leapseconds, the resulting TZif file would have incorrect 
> transitions because each leap second would be applied twice.


 ???? Oops -- I should not have omitted the time of day of
 ???? the switches from the Zone lines -- sorry for the confusion.

 ???? The complete lines must have a time of day, of course:

 ??????? Zone?? Etc/TAI? 0:00:10 - TAI?? 1972 Jul? 1? 0:00:00u
 ??????????????????????? 0:00:11 - TAI?? 1973 Jan? 1? 0:00:00u
 ??????????????????????? ....
 ??????????????????????? 0:00:35 - TAI?? 2015 Jul? 1? 0:00:00u
 ??????????????????????? 0:00:36 - TAI?? 2017 Jan? 1? 0:00:00u
 ??????????????????????? 0:00:37 - TAI?? 2020 Jun 28? 0:00:00u
 ??????????????????????? 0:00:37 - N_A

 ???? So the "adjacent ticks" you mention are in fact
 ???? the TAI values 1972-07-01T00:00:09 for UTC = 1972-06-30T23:59:59Z
 ??????????????? and 1972-07-01T00:00:11 for UTC = 1972-07-01T00:00:00Z.
 ???? Of course, these ticks of TAI are not adjacent: the TAI value
 ???? 1972-07-01T00:00:10 in between belongs to the leap second
 ???? UTC = 1972-06-30T23:59:60Z.

 ???? The Zone lines for right/Etc/TAI would give TAI as a function of
 ???? TAI - 10 s, so they would get the constant STDOFF value 0:00:10.
 ???? (And, yes, in this case the STDOFF value after 2020-06-28 is known.)

 ???? That TAI can be considered as a tzdb "timezone" is an observation
 ???? by Steve Allen, if I remember correctly.

 ???? Michael Deckers.



From eggert at cs.ucla.edu  Sat Dec  7 01:21:35 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Fri, 6 Dec 2019 17:21:35 -0800
Subject: [tz] Link Suggestion for your Website Resources page
In-Reply-To: <BYAPR06MB3879F72F027C338B6464B33DC25E0@BYAPR06MB3879.namprd06.prod.outlook.com>
References: <1581552221.1077255.1575610057569@ip-10-1-0-82.ec2.internal>
 <BYAPR06MB3879F72F027C338B6464B33DC25E0@BYAPR06MB3879.namprd06.prod.outlook.com>
Message-ID: <0e0a21a0-2719-2921-b955-cb08852038ef@cs.ucla.edu>

I replied privately that the link doesn't seem appropriate for us.


From Benjamin.Weiser at inrix.com  Fri Dec  6 21:23:41 2019
From: Benjamin.Weiser at inrix.com (Benjamin Weiser)
Date: Fri, 6 Dec 2019 21:23:41 +0000
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
Message-ID: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>

Thanks Rodrigo,

Do you mind explaining how you would parse America/Sao_Paulo? I see the note acknowledging Daylight Savings was scrapped, but not sure how you are getting that value correctly.

We are using a JODA library, and my understanding is it finds the timezone under the ?Zone? section, such as America/Sao_Paulo, and finds the bottom most value for the most current timezone.

For America/Sao_Paulo it says:
-3:00      Brazil     -03/-02

Are we not looking in the correct place?  In the ?Rule? section I don?t see anything that would give me -3:00 without DST.

Thanks

From: Rodrigo Br?ning Wessler <madigo at gmail.com>
Sent: Friday, December 6, 2019 12:56 PM
To: Benjamin Weiser <Benjamin.Weiser at inrix.com>
Cc: Jon Skeet <skeet at pobox.com>; tz at iana.org
Subject: Re: [tz] incorrect timezone info from tar files

Brazilian time zone rules was updated and released in version 2019b.

I'm using this version without issues.

On Fri, Dec 6, 2019 at 5:28 PM Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:
I do see a lot of these have recently updated.

I still see an issue with Brazil. Are those to be assumed as updated as well? I?m still seeing, for example in America/Sao_Paulo:

Zone America/Sao_Paulo             -3:06:28 -             LMT       1914
                                                -3:00      Brazil     -03/-02 1963 Oct 23  0:00
                                                -3:00      1:00        -02          1964
                                                -3:00      Brazil     -03/-02

The last line would indicate that its still following daylight savings, which Brazil scrapped this year.
 -3:00     Brazil     -03/-02

From: Benjamin Weiser
Sent: Monday, December 2, 2019 10:59 AM
To: Jon Skeet <skeet at pobox.com<mailto:skeet at pobox.com>>
Cc: tz at iana.org<mailto:tz at iana.org>
Subject: RE: [tz] incorrect timezone info from tar files

Thank you Jon,

I will have the dev take a look at why his tools are not refreshing the data correctly.  I do see the correct values in the links that you provided and in the download I mentioned. We were in the process of consolidating two teams that were sourcing TimeZones from different data sources. The team using IANA was claiming they were refreshing, so something must be going wrong with their tools as you suggested.

I appreciate the feedback.

From: Jon Skeet <skeet at pobox.com<mailto:skeet at pobox.com>>
Sent: Monday, December 2, 2019 9:49 AM
To: Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>>
Cc: tz at iana.org<mailto:tz at iana.org>
Subject: Re: [tz] incorrect timezone info from tar files

Could you clarify exactly how you derived your table, in terms of the IANA data?

If you look at https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnodatime.org%2Ftzvalidate%2Fgenerate%3Fversion%3D2019c%26zone%3DEurope%2FIstanbul&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7C6ce9b6589b6c4178083e08d77a8eac54%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C0%7C637112625523354252&sdata=EyV738S01v1f8M%2Bv6W3GWJSsN5Gm85dDGMgkw12wt60%3D&reserved=0> - which is generated from IANA data - it shows DST changes stopping in September 2016, just as you said.

Likewise if you look at the current source data<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feggert%2Ftz%2Fblob%2F1a27ec76bc436a64070461bbbf28e0511c7cf3b8%2Feurope%23L3889&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7C6ce9b6589b6c4178083e08d77a8eac54%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C0%7C637112625523364245&sdata=2OZzzLrWNzNYo1v8pbs0BJIJ5hnVfiuoP60BsqLyiM4%3D&reserved=0>, you'll see the same result.

I suspect this is a problem of data interpretation rather than anything else.

Jon


On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser at inrix.com<mailto:Benjamin.Weiser at inrix.com>> wrote:
Hello,

I?d like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Ftime-zones&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7C6ce9b6589b6c4178083e08d77a8eac54%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C0%7C637112625523364245&sdata=APGcT40OlXZM1HF%2Fty%2FrAV9IbLdxe39xZDdOAuy7BZY%3D&reserved=0>

For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST.

I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST)


TimeZone
UTC Offset
ObservesDST
IANA_UTC_offset:
IANA_ObservesDST:
America/Campo_Grande
-4
0
-4
1
America/Sao_Paulo
-3
0
-3
1
America/St_Johns
-3.5
1
-3
1
Asia/Sakhalin
11
0
10
0
Australia/Adelaide
9.5
1
9
1
Australia/Darwin
9.5
0
9
0
Australia/Lord_Howe
10.5
1
10
1
Europe/Istanbul
3
0
2
1
Indian/Cocos
6.5
0
6
0
Pacific/Chatham
12.75
1
12
1

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191206/1d56b66b/attachment.htm>

From eggert at cs.ucla.edu  Sat Dec  7 09:39:25 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Sat, 7 Dec 2019 01:39:25 -0800
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
 <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
Message-ID: <784a4867-6b1a-a731-9c05-b7804ef4a71f@cs.ucla.edu>

On 12/6/19 1:23 PM, Benjamin Weiser wrote:
> In the ?Rule? section I don?t see anything that would give me -3:00 without DST.

It sounds like you're looking at it backwards. There's nothing in the "Rule
Brazil" section that will give DST after February 2019. So there's no DST after
February 2019.


From kre at munnari.OZ.AU  Sat Dec  7 11:39:57 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Sat, 07 Dec 2019 18:39:57 +0700
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
References: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
 <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
Message-ID: <4667.1575718797@jinx.noi.kre.to>

    Date:        Fri, 6 Dec 2019 21:23:41 +0000
    From:        Benjamin Weiser <Benjamin.Weiser at inrix.com>
    Message-ID:  <BYAPR14MB30633C1E816B79A2B5935F18E85F0 at BYAPR14MB3063.namprd14.prod.outlook.com>

What may be confusing here, is that what this says:

	For America/Sao_Paulo it says:
	-3:00      Brazil     -03/-02

is that for Sao Paulo (for the timezone we call America/Sao_Paulo) the
standard offset from UTC is -3:00 (3 hours west of Greenwich), when
summer time applies is governed by the "Brazil" rules, and the names
of the time (the abbreviations used) are "-03" when it is not summer
time, and "-02" when it is summer time (like EST and EDT in the US).

That's important, the -03/-02 are *not* UTC offsets, they are labels.

A few years ago this might have instead been something like

	-3:00      Brazil     EBRT/EBRST

using (most probably not those) invented names for the time in winter/summer.
But many of the invented names were removed, and replaced by simple
numeric names that indicate what offset is applying - but they are
just names (labels), they specify nothing else.

That a name exists to label summer time when it applies, does not mean it
ever does, and more likely, does not mean it applies any particular year.
Those names are used for times in the past when summer time was used
(and perhaps again in the future if summer time turns on again.)

This is another important thing to remember - time conversions must
work correctly for times in the past, not just the time today.  If I
ask what time it was in Sao Paulo at 11:30 Dec 7 2018 UTC, then I
need to get the conversion done knowing that it was summer time then.
That summer time is not being used this summer does not mean it was
not used last summer, and that the answer to that question would be
different if the year requested was 2019 instead of 2018 simply
reflects how the rules are different this year than they were last year.

The only way to discover if (and if so, when) summer time turns on
and off, in this case is to look at the Brazil rules (elsewhere in the
same source file).

The relevant (recent) rules for Brazil end with (all the comments deleted):

Rule    Brazil  2008    2017    -       Oct     Sun>=15 0:00    1:00    -
Rule    Brazil  2008    2011    -       Feb     Sun>=15 0:00    0       -
Rule    Brazil  2012    only    -       Feb     Sun>=22 0:00    0       -
Rule    Brazil  2013    2014    -       Feb     Sun>=15 0:00    0       -  
Rule    Brazil  2015    only    -       Feb     Sun>=22 0:00    0       -
Rule    Brazil  2016    2019    -       Feb     Sun>=15 0:00    0       -
Rule    Brazil  2018    only    -       Nov     Sun>=1  0:00    1:00    -

The first and last of those are the only ones (shown) that enable summer
time (there are of course others for earlier years, but they're not
relevant here, so I didn't include them).

The first (as it indicates) applied from 2008 to 2017.   The last applied
in 2018 (only).   There is no rule there for turning on summer time in
2019, or any later year.

The intervening rules are all for when summer time turned off in the
various years during this period.  The last of those says summer time
(the one that started in early November 2018) ended in mid February, 2019
(as it had in most of the years since 2008, just 2012 and 2015 ended a
week later)   All of this is visible in those Rule lines.

After that there is nothing.   Summer time turned off in Feb 2019, and
never turns on again (and so never needs to turn off again either).
That is, until the politicians in Brazil decide to change things again,
in which case, after we find out what the new rules will be, we will
need a new release of tzdata to contain that new information.

The Rules are used because there are many different timezones in
Brazil, with different UTC offsets, and different labels to name
what the time is called (for whatever that is worth), but they all
turn summer time on and off (when they use it at all) according to
the same rules - so the rules are specified once, and the zones which
have summer time just reference them.   Zones in Brazil which never
use(d) summer time would not reference the Brazil rules, but simply
specify what UTC offset applies, and what to label the time as.

There aren't, but could be, some zones in Brazil which used a
different set of rules, than the others (turned summer time on
and off on different dates).  If that were the case, then there
would be another set of rules (perhaps "Brazil2" or "Tropical-Brazil"
or "Northern-Brazil" depending on what seemed appropriate) to
specify those different rules, and the relevant zones would refer
to those - that happens in Australia, where the various states
do whatever they like in this area, and while they seem to all be
in sync right now (for those states which use summer time), they haven't
been in the past.   So in AU, each state gets its own set of rules (they
cannot be combined, ever, regardless of the current rules all being
the same, or conversions of times in the past would not be correct).

Other zones (not from Brazil), which have their own unique summer time
rules, not shared with any other zones, might not bother with separate
rules and simply specify the transitions in the zone definition.

Unless you are used to reading the tzdb data source files, it is generally
best not to try - instead run a tzdb compiler (like zic) and then dump
the binary format files, and see when the transitions actually occur.
That's a much much more reliable way of verifying the data then guessing
at how to interpret the tzdata sources.

kre



From guy at alum.mit.edu  Sun Dec  8 03:44:44 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sat, 7 Dec 2019 19:44:44 -0800
Subject: [tz] incorrect timezone info from tar files
In-Reply-To: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
References: <MN2PR14MB3072F480F2F7CEBFB587FA15E8450@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CA+5fHtJ3mpGjCXabxNobg+v9H2hDgLnKv6bAxOQCfDjjO+7=jw@mail.gmail.com>
 <MN2PR14MB3072D9EBB9F7DE86692DC06EE8430@MN2PR14MB3072.namprd14.prod.outlook.com>
 <MN2PR14MB3072CAFF6AA06AF43BC4EF39E85C0@MN2PR14MB3072.namprd14.prod.outlook.com>
 <CABbzgKY1YJZ6ewDM=-JmbxBt7vQ+NjqZcKKRGuchfOMgc5ZfbA@mail.gmail.com>
 <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com>
Message-ID: <BA998194-BC78-42C1-BA82-0E4316B43FE3@alum.mit.edu>

On Dec 6, 2019, at 1:23 PM, Benjamin Weiser <Benjamin.Weiser at inrix.com> wrote:

> Do you mind explaining how you would parse America/Sao_Paulo?

Zone America/Sao_Paulo            -3:06:28   -          LMT       1914
                                  -3:00      Brazil     -03/-02   1963 Oct 23  0:00
                                  -3:00      1:00       -02       1964
                                  -3:00      Brazil     -03/-02

This says:

	Until 1914, America/Sao_Paulo is 3 hours, 6 minutes, and 28 seconds behind GMT, I guess - that's local mean time, "LMT", and labeled as such;

	from 1914 to 1963-10-23, it follows the "Brazil" rules for summer/daylight saving time, with it being 3 hours behind GMT/UTC when summer time is not in effect and 2 hours behind GMT/UTC when summer time is in effect;

	from 1963-10-23 to 1964-01-01, its time is 1 hour ahead of standard time, i.e. 2 hours behind GMT/UTC;

	from 1964-01-01 on, it again follows the "Brazil" rules.

I mentioned the way to interpret the "Brazil" rules in a previous email.

Also read Robert Elz's more detailed explanation.

> I see the note acknowledging Daylight Savings was scrapped, but not sure how you are getting that value correctly.

From that last line *and* from the "Brazil" rules.
 
> We are using a JODA library, and my understanding is it finds the timezone under the ?Zone? section, such as America/Sao_Paulo, and finds the bottom most value for the most current timezone.

Presumably Joda-Time can process dates and times other than "right now", which means that it does *not* necessarily find the bottommost value, because that value might not be the one that applies - if it's 1963-11-27, for example, the *previous* line:

                                  -3:00      1:00       -02       1964
applies.

If a line that has a name, rather than a number, in the second field applies, it would also have to look at the "Rules" section and find the appropriate one of the "Brazil" entries there.

(Or maybe it does processing similar to zic, reading the entire file and building a table of transition timestamps and UTC offsets - or just reads compiled zic files.)

> For America/Sao_Paulo it says:
> -3:00      Brazil     -03/-02
>  
> Are we not looking in the correct place?  In the ?Rule? section I don?t see anything that would give me -3:00 without DST.

See my earlier email about the "Rules" section.


From stefan.rueger at theblueorange.space  Sat Dec  7 17:21:05 2019
From: stefan.rueger at theblueorange.space (Stefan Rueger)
Date: Sat, 7 Dec 2019 17:21:05 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
Message-ID: <20191207172105.GA18617@cedar>

Looks like zdump claims Dublin has DST during winter, not summer:

$ ./zdump -i -c2020,2021 Europe/Dublin

TZ="Europe/Dublin"
-	-	+00	GMT	1
2020-03-29	02	+01	IST
2020-10-25	01	+00	GMT	1

Compare with the output for London, which is as I would expect:

$ ./zdump -i -c2020,2021 Europe/London

TZ="Europe/London"
-	-	+00	GMT
2020-03-29	02	+01	BST	1
2020-10-25	01	+00	GMT

Generally, I think it's neater if the time stretches with the larger GMT values are considered DST. This is almost always true, except for Europe/Dublin, Eire, Africa/Casablanca and Africa/El_Aaiun.

Morocco (and Western Sahara) change the time to have shorter fasts during Ramadan, so to speak to *not* save daylight. I would therefore still argue that the time outside Ramadan should be considered DST and the time during Ramadan the non-DST time.

I am aware that the view "DST means larger GMT value" is not a precise definition (a region that change times zones in quick succession might easily accrue more than two GMT values within a few years). It's therefore not a great candidate for implementation in zic/zdump. However, I hold that periodic *future* annual back-and-forth switches should adopt that principle.

Anyway, over to you


Stefan

PS: You are providing an *amazing* service - many thanks for that!


From eggert at cs.ucla.edu  Tue Dec 10 23:02:33 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Tue, 10 Dec 2019 15:02:33 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191207172105.GA18617@cedar>
References: <20191207172105.GA18617@cedar>
Message-ID: <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>

On 12/7/19 9:21 AM, Stefan Rueger wrote:
> I think it's neater if the time stretches with the larger GMT values are considered DST.

It is a controversial area because there are two competing objectives: 
having standard time be the standard UT offset ('std' in POSIX) vs 
having DST's offset be greater than standard time's. As noted in the 
'europe' file, in a comment from Joseph S. Myers (2005-01-26):

"(Note that the time in the Republic of Ireland since 1968 has been 
defined in terms of standard time being GMT+1 with a period of winter 
time when it is GMT, rather than standard time being GMT with a period 
of summer time being GMT+1.)"

and we eventually went with that interpretation, as opposed to the one 
you suggested.

Morocco is similar, as are some other historic uses of "winter time" as 
DST. (Whether this practice "saves" daylight depends on whether one 
prefers morning to evening daylight. :-)

If you prefer the other interpretation, you can get it with 'make 
rearguard_tarballs'.


From guy at alum.mit.edu  Tue Dec 10 23:43:19 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Tue, 10 Dec 2019 15:43:19 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
Message-ID: <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>

On Dec 10, 2019, at 3:02 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/7/19 9:21 AM, Stefan Rueger wrote:
>> I think it's neater if the time stretches with the larger GMT values are considered DST.
> 
> It is a controversial area because there are two competing objectives: having standard time be the standard UT offset ('std' in POSIX) vs having DST's offset be greater than standard time's. As noted in the 'europe' file, in a comment from Joseph S. Myers (2005-01-26):
> 
> "(Note that the time in the Republic of Ireland since 1968 has been defined in terms of standard time being GMT+1 with a period of winter time when it is GMT, rather than standard time being GMT with a period of summer time being GMT+1.)"
> 
> and we eventually went with that interpretation, as opposed to the one you suggested.

I.e., it *is* DST, except that the "S" stands for "spending" rather than "saving". :-)

Either that, or "S" stands for "shifting", in both the case of shifting the clock forward from standard time in the spring and the case of shifting the clock *backward* from standard time in the autumn.  (That also has the advantage of not claiming anything's "saved".)

C18 says that

	Some functions deal with local time, which is the calendar time expressed for some specific time zone, and with Daylight Saving Time, which is a temporary change in the algorithm for determining local time. The local time zone and Daylight Saving Time are implementation-defined.

and that

	The value of tm_isdst is positive if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and negative if the information is not available.

which leaves the interpretation to the implementation, as it doesn't say whether the time when the temporary change is *not* in effect must be the legally-defined "standard time" or not, nor whether the "temporary change" must set the clock forward.

POSIX appears not to disallow a TZ setting in which the "dst" offset is less than the "std" offset, unless I'm missing something, so, again, I'm not sure any standard forbids setting the clock *backwards* for "Daylight Saving Time".

From eggert at cs.ucla.edu  Wed Dec 11 18:09:45 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Wed, 11 Dec 2019 10:09:45 -0800
Subject: [tz] Iceland may move from +00 to -01
Message-ID: <392e16c9-8010-e139-b41d-bfca41d64d9a@cs.ucla.edu>

Since 1968 Reykjav?k has been about 1.5 hours ahead of mean solar time. 
The government of Iceland recently asked people which of three things 
they wanted to do about this, and the survey results were:

   4% - educational campaign to encourage people to go to bed earlier
  37% - leave the clocks alone
  56% - change from +00 to -01

The prime minister's office is drafting a bill to implement the majority 
opinion: this would undo the 1968 change from -01/+00 (with DST) to 
permanent +00, and would revert to permanent -01, which was observed 
1908-1916 and 1922-1938.

Although I've seen many proposals from around the world to change the 
clocks, this bill seems to have a real chance of passing so I thought 
I'd give the list a heads-up.

My source:

Fontaine A. Most Icelanders support changing Iceland?s time zone. 
Reykjav?k Grapevine. 2019-12-11. 
https://grapevine.is/news/2019/12/11/most-icelanders-support-changing-icelands-time-zone/


From michael.h.deckers at googlemail.com  Wed Dec 11 18:12:25 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Wed, 11 Dec 2019 18:12:25 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
Message-ID: <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>


 ?? On 2019-12-10 23:43, Guy Harris wrote:

> POSIX appears not to disallow a TZ setting in which the "dst" offset is less than the "std" offset, unless I'm missing something, so, again, I'm not sure any standard forbids setting the clock *backwards* for "Daylight Saving Time".


 ?? I see this more as a problem of upward compatibility of tzdb, not
 ?? of POSIX: for more than twenty years, the tzdb description in
 ?? newctime.3 has guaranteed (in addition to what C and POSIX require)
 ?? that
 ????? "Tm_isdst is non-zero if summer time is in effect"
 ?? and probably the "if" was even meant as "if and only if".

 ?? This is no longer true since 2018c, but the interface description
 ?? in newctime.3 was changed only in 2018f (without advert in NEWS). Some
 ?? programs had relied on the old interface description, and have since
 ?? adapted their functionality.

 ?? For others, I do not know. For instance, the PHP date_format() 
function has
 ?? a format specifier "I" for an indication of winter and summer time. 
Has the
 ?? semantics of that format specifier changed? Or has it been removed?

 ?? Due to the importance of tzdb, and its widespread use, even tiny changes
 ?? in its external interfaces may cause compatibility problems. Using
 ?? "rearguard" tzdb data can help in transitions.

 ?? Michael Deckers.



From eggert at cs.ucla.edu  Wed Dec 11 18:39:07 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Wed, 11 Dec 2019 10:39:07 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
Message-ID: <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>

On 12/11/19 10:12 AM, Michael H Deckers wrote:
>     the tzdb description in
>  ?? newctime.3 ... guaranteed (in addition to what C and POSIX require)
>  ?? that
>  ????? "Tm_isdst is non-zero if summer time is in effect"
>  ?? and probably the "if" was even meant as "if and only if".

I don't think that old wording was ever intended to mean that tm_isdst 
was to be set only in summer, or even only in daylight-saving periods 
that were used in summer and adjacent time periods. Such a meaning would 
have been contradicted by longstanding data, such as Belize's observance 
of DST from October through February in late 1918 through early 1943.

Instead, it was merely sloppy wording where "summer time" was 
incorrectly used as a synonym for "daylight saving time", the wording 
that is in the relevant standards and that corresponds to the 
abbreviation "tm_isdst".


From michael.h.deckers at googlemail.com  Wed Dec 11 21:39:00 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Wed, 11 Dec 2019 21:39:00 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
Message-ID: <402c5bee-6e5f-0c8a-c0e1-d082c986f33d@googlemail.com>


 ?? On 2019-12-11 18:39, Paul Eggert wrote:

> Instead, it was merely sloppy wording where "summer time" was 
> incorrectly used as a synonym for "daylight saving time", the wording 
> that is in the relevant standards and that corresponds to the 
> abbreviation "tm_isdst".


 ?? You are right, "summer time" would be a "sloppy wording"
 ?? for winter time in Ireland.

 ?? Michael Deckers.



From marc.sackeli at gmail.com  Wed Dec 11 23:14:10 2019
From: marc.sackeli at gmail.com (Marc Sackeli)
Date: Wed, 11 Dec 2019 15:14:10 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
Message-ID: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>

I apologize if this is a repeat question, but this question pertains
specifically to how the tz database might change if individual US states
start adhering to their own DST rules.

There has been a wave of legislation
<https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#2015%E2%80%932019_Proposals_for_the_introduction_of_Year-Round_DST>
coming
from individual states trying to shift towards a year-round DST model.
While several states have successfully passed this legislation, their
ability to shift is reliant on federal approval. Arizona has been able to
drum to their own beat on DST, and I don't think it's far fetched to think
other states might be allowed to do so in the future as well.

If this is a potential outcome, is there an idea of how the tz database
would adapt to this change? My guess is that new entries would be created
to allow us to delineate between these states. We are currently covered if
California decides to change thanks to America/Los_Angeles, but what if
Oregon or Tennessee decides they want to change? Does this mean
America/Portland and America/Nashville would be created? Or perhaps
America/Oregon and America/Tennessee?

Any thoughts would be appreciated.

-Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191211/1ebd9f8d/attachment.htm>

From eggert at cs.ucla.edu  Wed Dec 11 23:20:09 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Wed, 11 Dec 2019 15:20:09 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
Message-ID: <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>

On 12/11/19 3:14 PM, Marc Sackeli wrote:
> If this is a potential outcome, is there an idea of how the tz database 
> would adapt to this change? My guess is that new entries would be 
> created to allow us to delineate between these states.

Right.

> We are currently 
> covered if California decides to change thanks to America/Los_Angeles,

Not if the rest of the Pacific time zone decides not to change. In that 
case, we'd need to create America/Seattle etc. We'd prefer city names to 
state names, as that's the convention.


From guy at alum.mit.edu  Wed Dec 11 23:21:15 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Wed, 11 Dec 2019 15:21:15 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
Message-ID: <F176D8D8-EA73-4240-AF5F-4BBFA36DEC22@alum.mit.edu>

On Dec 11, 2019, at 3:14 PM, Marc Sackeli <marc.sackeli at gmail.com> wrote:

> If this is a potential outcome, is there an idea of how the tz database would adapt to this change? My guess is that new entries would be created to allow us to delineate between these states.

Yes.

> We are currently covered if California decides to change thanks to America/Los_Angeles, but what if Oregon or Tennessee decides they want to change? Does this mean America/Portland and America/Nashville would be created?

Yes.

> Or perhaps America/Oregon and America/Tennessee?

No.

	ftp://ftp.iana.org/tz/tzdb-2018g/theory.html

"Names of timezones

Each timezone has a unique name. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like "Ruthenia" instead of the timezone name "Europe/Uzhgorod". If geolocation information is available, a selection interface can locate the user on a timezone map or prioritize names that are geographically close. For an example selection interface, see the tzselect program in the tz code. The Unicode Common Locale Data Repository contains data that may be useful for other selection interfaces; it maps timezone names like Europe/Uzhgorod to CLDR names like uauzh which are in turn mapped to locale-dependent strings like "Uzhhorod", "Ungv?r", "???????", and "?????".

The naming conventions attempt to strike a balance among the following goals:

	? Uniquely identify every timezone where clocks have agreed since 1970. This is essential for the intended use: static clocks keeping local civil time.
	? Indicate to experts where the timezone's clocks typically are.
	? Be robust in the presence of political changes. For example, names of countries are ordinarily not used, to avoid incompatibilities when countries change their name (e.g., Zaire?Congo) or when locations change countries (e.g., Hong Kong from UK colony to China).
	? Be portable to a wide variety of implementations.
	? Use a consistent naming conventions over the entire world.
Names normally have the form AREA/LOCATION, where AREA is a continent or ocean, and LOCATION is a specific location within the area. North and South America share the same area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York', and 'Pacific/Honolulu'. Some names are further qualified to help avoid confusion; for example, 'America/Indiana/Petersburg' distinguishes Petersburg, Indiana from other Petersburgs in America.

Here are the general guidelines used for choosing timezone names, in decreasing order of importance:

	? Use only valid POSIX file name components (i.e., the parts of names other than '/'). Do not use the file name components '.' and '..'. Within a file name component, use only ASCIIletters, '.', '-' and '_'. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with '-'. E.g., prefer Asia/Brunei to Asia/Bandar_Seri_Begawan. Exceptions: see the discussion of legacy names below.
	? A name must not be empty, or contain '//', or start or end with '/'.
	? Do not use names that differ only in case. Although the reference implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case.
	? If one name A is an initial prefix of another name AB (ignoring case), then B must not start with '/', as a regular file cannot have the same name as a directory in POSIX. For example, America/New_York precludes America/New_York/Bronx.
	? Uninhabited regions like the North Pole and Bouvet Island do not need locations, since local time is not defined there.
	? There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory.
	? If all the clocks in a timezone have agreed since 1970, do not bother to include more than one timezone even if some of the clocks disagreed before 1970. Otherwise these tables would become annoyingly large.
	? If a name is ambiguous, use a less ambiguous alternative; e.g., many cities are named San Jos? and Georgetown, so prefer America/Costa_Rica to America/San_Jose and America/Guyana to America/Georgetown.
	? Keep locations compact. Use cities or small islands, not countries or regions, so that any future changes do not split individual locations into different timezones. E.g., prefer Europe/Paris to Europe/France, since France has had multiple time zones.
	? Use mainstream English spelling, e.g., prefer Europe/Rome to Europa/Roma, and prefer Europe/Athens to the Greek ??????/????? or the Romanized Evr?pi/Ath?na. The POSIX file name restrictions encourage this guideline.
	? Use the most populous among locations in a region, e.g., prefer Asia/Shanghai to Asia/Beijing. Among locations with similar populations, pick the best-known location, e.g., prefer Europe/Rome to Europe/Milan.
	? Use the singular form, e.g., prefer Atlantic/Canary to Atlantic/Canaries.
	? Omit common suffixes like '_Islands' and '_City', unless that would lead to ambiguity. E.g., prefer America/Cayman to America/Cayman_Islands and America/Guatemala toAmerica/Guatemala_City, but prefer America/Mexico_City to America/Mexico because the country of Mexico has several time zones.
	? Use '_' to represent a space.
	? Omit '.' from abbreviations in names. E.g., prefer Atlantic/St_Helena to Atlantic/St._Helena.
	? Do not change established names if they only marginally violate the above guidelines. For example, do not change the existing name Europe/Rome to Europe/Milan merely because Milan's population has grown to be somewhat greater than Rome's.
	? If a name is changed, put its old spelling in the 'backward' file. This means old spellings will continue to work."

In particular, note

	Keep locations compact. Use cities or small islands, not countries or regions, so that any future changes do not split individual locations into different timezones. E.g., prefer Europe/Paris to Europe/France, since France has had multiple time zones.

From marc.sackeli at gmail.com  Wed Dec 11 23:30:38 2019
From: marc.sackeli at gmail.com (Marc Sackeli)
Date: Wed, 11 Dec 2019 15:30:38 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
 <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
Message-ID: <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>

Understood.  From the looks of it, state names are only used when the state
itself doesn't adhere to a single timezone. North Dakota, Kentucky,
Indiana, etc.

Thanks for the response, that's clear things up for me.



On Wed, Dec 11, 2019 at 3:20 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/11/19 3:14 PM, Marc Sackeli wrote:
> > If this is a potential outcome, is there an idea of how the tz database
> > would adapt to this change? My guess is that new entries would be
> > created to allow us to delineate between these states.
>
> Right.
>
> > We are currently
> > covered if California decides to change thanks to America/Los_Angeles,
>
> Not if the rest of the Pacific time zone decides not to change. In that
> case, we'd need to create America/Seattle etc. We'd prefer city names to
> state names, as that's the convention.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191211/f0343959/attachment.htm>

From eggert at cs.ucla.edu  Wed Dec 11 23:37:31 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Wed, 11 Dec 2019 15:37:31 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
 <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
 <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>
Message-ID: <deeeb23e-3d4a-7e54-72d6-cc81f0f8bc94@cs.ucla.edu>

On 12/11/19 3:30 PM, Marc Sackeli wrote:
>  From the looks of it, state names are only used when the state itself 
> doesn't adhere to a single timezone.

Yes, but that's for directory names, e.g., America/Indiana/Petersburg; 
there is no America/Indiana zone. This is more to handle 
ambiguity/obscurity.

We will be in trouble if the state of New York splits, since 
America/New_York cannot be a directory name.


From marc.sackeli at gmail.com  Thu Dec 12 00:49:44 2019
From: marc.sackeli at gmail.com (Marc Sackeli)
Date: Wed, 11 Dec 2019 16:49:44 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <deeeb23e-3d4a-7e54-72d6-cc81f0f8bc94@cs.ucla.edu>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
 <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
 <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>
 <deeeb23e-3d4a-7e54-72d6-cc81f0f8bc94@cs.ucla.edu>
Message-ID: <CAPEb5JJad49K6HZMUXymiKbqM6aCdV=J1LXFDcef+-cOS0seGA@mail.gmail.com>

Guy, Paul,

Thanks for the follow ups. I've read the doc that Guy sent over and it
helped put things into context, especially the directory usage.

On 12/11/19 3:37 PM, Paul Eggert wrote:
> We will be in trouble if the state of New York splits,
> since America/New_York cannot be a directory name.
That is a tricky scenario. Thankfully that type of naming overlap seems
like an outlier. I'd like to think we are OK there given New York's
position within EST.

On a side note, how are you both extracting and formatting my quotes so
nicely in your replies? I manually made mine to match your format.

Best,
Marc

On Wed, Dec 11, 2019 at 3:37 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 12/11/19 3:30 PM, Marc Sackeli wrote:
> >  From the looks of it, state names are only used when the state itself
> > doesn't adhere to a single timezone.
>
> Yes, but that's for directory names, e.g., America/Indiana/Petersburg;
> there is no America/Indiana zone. This is more to handle
> ambiguity/obscurity.
>
> We will be in trouble if the state of New York splits, since
> America/New_York cannot be a directory name.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191211/d6cdf43b/attachment.htm>

From Brian.Inglis at SystematicSw.ab.ca  Thu Dec 12 16:29:03 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Thu, 12 Dec 2019 09:29:03 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
Message-ID: <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>

On 2019-12-11 11:39, Paul Eggert wrote:
> On 12/11/19 10:12 AM, Michael H Deckers wrote:
>> ??? the tzdb description in
>> ??? newctime.3 ... guaranteed (in addition to what C and POSIX require)
>> ??? that
>> ?????? "Tm_isdst is non-zero if summer time is in effect"
>> ??? and probably the "if" was even meant as "if and only if".
> 
> I don't think that old wording was ever intended to mean that tm_isdst was to be
> set only in summer, or even only in daylight-saving periods that were used in
> summer and adjacent time periods. Such a meaning would have been contradicted by
> longstanding data, such as Belize's observance of DST from October through
> February in late 1918 through early 1943.
> 
> Instead, it was merely sloppy wording where "summer time" was incorrectly used
> as a synonym for "daylight saving time", the wording that is in the relevant
> standards and that corresponds to the abbreviation "tm_isdst".

It is more likely that the term was correctly used in some other locale, where
summer (and winter) time is often the legal wording in various languages, where
the equivalents of "daylight saving" and "standard", used in North America, are
not used or don't exist; sometimes the equivalents of "civil time" and "advanced
time" are used instead, but nothing helps when standard is advanced relative to
the alternative.

I preferred whichever reference used the terms "standard time" and "alternative
time", as that seems to be a more accurate wording for current (existing) usage.
Of course, summer and winter time are also useful and accurate, but the offset
relative values may not be as expected.

Perhaps tm_isdst should always be set to -1 for inverted zones, where it does
not represent summer or saving time, or even set it for all zones permanently to
-1?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


From Brian.Inglis at SystematicSw.ab.ca  Thu Dec 12 17:20:26 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Thu, 12 Dec 2019 10:20:26 -0700
Subject: [tz] EU and Brexit Time Borders
Message-ID: <9e73addd-8b92-93c6-c89d-cf143a9aab8a@SystematicSw.ab.ca>

EU member states get to decide whether to stay on summer or standard time:

https://www.independent.ie/business/brexit/meps-vote-to-end-daylight-savings-which-may-result-in-two-irish-time-zones-37955161.html

What will Ireland do, and will Ulster follow Irish or UK time?

https://www.independent.co.uk/news/uk/politics/brexit-irish-border-time-clock-change-daylight-savings-boris-johnson-a9169326.html

Will UK follow, staying on GMT or BST, or keep switching?

https://www.rospa.com/media/documents/road-safety/consultation-responses/discontinuing-seasonal-changes-of-time.pdf

"Under the new legislation, governments opting to make summer-time permanent
would adjust their clocks for the last time on the last Sunday in March 2021.
For those choosing permanent standard time, known as permanent winter-time, the
final clock change would be on the last Sunday of October 2021."

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


From eggert at cs.ucla.edu  Thu Dec 12 20:59:34 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Thu, 12 Dec 2019 12:59:34 -0800
Subject: [tz] Anticipated strategy for handling US state DST rule changes
In-Reply-To: <DM6PR04MB428329B7C1C67F1558E2B486A2550@DM6PR04MB4283.namprd04.prod.outlook.com>
References: <CAPEb5J+E1Gkm9y3LEsQa5br_cAe0FU2XmOZ6cyjTq5bPyEoUHw@mail.gmail.com>
 <43098a1e-5ed1-5663-d0fe-e135fddb7e17@cs.ucla.edu>
 <CAPEb5JKv--crfT=Vf9Wx_uCfY+Evw=k6X-SCiU8wEo4nVb_9rw@mail.gmail.com>
 <deeeb23e-3d4a-7e54-72d6-cc81f0f8bc94@cs.ucla.edu>
 <DM6PR04MB428329B7C1C67F1558E2B486A2550@DM6PR04MB4283.namprd04.prod.outlook.com>
Message-ID: <1476e19b-03b5-0171-a111-4d05e6b8ecae@cs.ucla.edu>

On 12/12/19 7:39 AM, David Braverman wrote:
> Can we use America/New_York_State/Buffalo, for example?

That would work, yes. But let's hope Buffalo stays aligned.


From kre at munnari.OZ.AU  Fri Dec 13 00:17:16 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Fri, 13 Dec 2019 07:17:16 +0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>
References: <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
Message-ID: <13633.1576196236@jinx.noi.kre.to>

    Date:        Thu, 12 Dec 2019 09:29:03 -0700
    From:        Brian Inglis <Brian.Inglis at SystematicSw.ab.ca>
    Message-ID:  <4e191681-6342-a5d3-e539-945a50fd11c3 at SystematicSw.ab.ca>

  | I preferred whichever reference used the terms "standard time"
  | and "alternative time",

That was POSIX, before it was changed (not yet published, but applied,
"alternative time" will no longer appear when the next edition is pubished)
based upon some input from this direction.

But, while I agree it was better, it's not good enough either - first
because there's not just two, and second, because there's no point giving
these things a name - whatever time it is (commonly agreed, whether
legislatively backed or not) is "standard time" - that's what it means
to be "standard".   The only other thing we can (at least currently) rely
upon is that there is a current offset from UTC (ie: that UTC is stable,
and the time anywhere is, for a short while anyway, a constant offset
from UTC - positive or negative (or 0)).

Some juristictions provide names for the various times, mostly for convenience
around the transitions, but none of them are very useful, and here we really
cannot rely upon any such thing existing.

tm_isdst was originally just intended as an index into tzname[] to get
the (assumed always to exist) "name" of the current time (nb: not timezone).
Both of the assumptions there are demonstrably false, first that there is
a name to get, and second that there are just two (0 or 1 in tm_isdst).
tzname[] is also an interface disaster, and should be retired, and if it
is, the sole rational reason for tm_isdst to exist at all will vanish, and
it can be deleted as well.

[The addition of -1 as a tm_isdst value "don't know" when it is used as
input to mktime() came later - as did mktime - that was a hack, still is].

But please people, we have had this discussion over and over, nothing is
going to change anytime in the forseeable future, neither to correct any
"bugs" that appear to exist (they don't - or not in this area) nor to
actually make the interface more sane.

There's no point continually discussing it.

kre



From olopierpa at gmail.com  Fri Dec 13 02:54:00 2019
From: olopierpa at gmail.com (Pierpaolo Bernardi)
Date: Fri, 13 Dec 2019 03:54:00 +0100
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <13633.1576196236@jinx.noi.kre.to>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
 <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>
 <13633.1576196236@jinx.noi.kre.to>
Message-ID: <CANY8u7F+z6-oH1N_GpEDye-yJt33Q1-6HofV1bXUk=LTydmp4A@mail.gmail.com>

On Fri, Dec 13, 2019 at 1:17 AM Robert Elz <kre at munnari.oz.au> wrote:

> But please people, we have had this discussion over and over, nothing is
> going to change anytime in the forseeable future, neither to correct any
> "bugs" that appear to exist (they don't - or not in this area) nor to
> actually make the interface more sane.

There's no chance to change the existing posix calls. But there's a
possibility to add a completely new set of calls which could
eventually supersede the current set as the recommended way to handle
time.


From kre at munnari.OZ.AU  Fri Dec 13 04:01:47 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Fri, 13 Dec 2019 11:01:47 +0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <CANY8u7F+z6-oH1N_GpEDye-yJt33Q1-6HofV1bXUk=LTydmp4A@mail.gmail.com>
References: <CANY8u7F+z6-oH1N_GpEDye-yJt33Q1-6HofV1bXUk=LTydmp4A@mail.gmail.com>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <b3a4c4c6-1cd8-deb1-4438-bfff71481399@googlemail.com>
 <6a97910d-3a62-2670-ab42-33ef6ce39b2c@cs.ucla.edu>
 <4e191681-6342-a5d3-e539-945a50fd11c3@SystematicSw.ab.ca>
 <13633.1576196236@jinx.noi.kre.to>
Message-ID: <2485.1576209707@jinx.noi.kre.to>

    Date:        Fri, 13 Dec 2019 03:54:00 +0100
    From:        Pierpaolo Bernardi <olopierpa at gmail.com>
    Message-ID:  <CANY8u7F+z6-oH1N_GpEDye-yJt33Q1-6HofV1bXUk=LTydmp4A at mail.gmail.com>

  | There's no chance to change the existing posix calls. But there's a
  | possibility to add a completely new set of calls which could

Yes, agreed.   That would be the way forward.

kre



From stefan.rueger at theblueorange.space  Wed Dec 11 19:23:27 2019
From: stefan.rueger at theblueorange.space (Stefan Rueger)
Date: Wed, 11 Dec 2019 19:23:27 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
Message-ID: <20191211192327.GA18736@cedar>

On Tue, Dec 10, 2019 at 23:43, Guy Harris wrote:
| I.e., it *is* DST, except that the "S" stands for "spending" rather than "saving". :-)

:-) It's mostly a matter of documentation and expectation. I for one have been surprised by the recent change of interpretation to the extent that I thought this is a bug - despite having read the documentation to a reasonable depth in 2017. I've changed my programme to no longer use isdst (or rely on what I thought isdst meant).

Can I suggest to make explicit in zdump's manpage (and other places) that isdst==1 doesn't necessarily mean clocks going forward. I believe that daylight saving time is widely understood to be synonymous with summer time: https://en.wikipedia.org/wiki/Daylight_saving_time Again, a simple case of noting in the documentation that this is not the intended interpretation here.

Cheers


Stefan

I feel there were missed opportunities, too, when developing standards: Rather than foregrounding time difference to GMT and isdst (1 for DXT "daylight changed time", 0 for normal and -1 for unknown) one might have foregrounded the difference to what the region considers its normal time zone and the current offset owing to DXT, if any. Using the current interpretation the DXT offset would be -1 for Ireland and 1 for the UK (while Antarctica/Troll would be 2 and Lord Howe Island 0.5). That way the difference to GMT would be the sum of slow changing (geographic timezone) and potentially annually changing (DXT) offsets. In my mind this would have been more informative and easier to understand than isdst.



From clive at davros.org  Fri Dec 13 22:13:36 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Fri, 13 Dec 2019 22:13:36 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191211192327.GA18736@cedar>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar>
Message-ID: <20191213221336.GE24121@davros.org>

Stefan Rueger said:
> I feel there were missed opportunities, too, when developing standards: Rather than foregrounding time difference to GMT and isdst (1 for DXT "daylight changed time", 0 for normal and -1 for unknown) one might have foregrounded the difference to what the region considers its normal time zone and the current offset owing to DXT, if any. Using the current interpretation the DXT offset would be -1 for Ireland and 1 for the UK (while Antarctica/Troll would be 2 and Lord Howe Island 0.5). That way the difference to GMT would be the sum of slow changing (geographic timezone) and potentially annually changing (DXT) offsets. In my mind this would have been more informative and easier to understand than isdst.

I don't disagree with you. The problem is that the original standards were
mostly written by US people who assume that the whole world works their way.
Where there's a clean sheet to start from, we can do better things [1], but
that's a lot harder with a large installed base.

The US-centric problem isn't new to this. I've lost count how many web
sites can't cope with the fact that I don't have a zip code or that I have
two middle initials, not one. I'm lucky that I don't have any non-ASCII
characters in my name; there's a whole nother minefield waiting there.

Allow me to point you at:
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
https://wiesmann.codiferes.net/wordpress/?p=15187&lang=en

[1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
internally for all timestamps, leaving the leap second mess to the
periphery.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646


From Brian.Inglis at SystematicSw.ab.ca  Sat Dec 14 06:20:39 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Fri, 13 Dec 2019 23:20:39 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191213221336.GE24121@davros.org>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
Message-ID: <c432c71d-0d97-767d-7726-3c62d5598047@SystematicSw.ab.ca>

On 2019-12-13 15:13, Clive D.W. Feather wrote:
> I don't disagree with you. The problem is that the original standards were
> mostly written by US people who assume that the whole world works their way.
> Where there's a clean sheet to start from, we can do better things [1], but
> that's a lot harder with a large installed base.

Is anyone aware of any plans to backport C++ work on chrono, date, tz, calendar,
etc. APIs to POSIX and/or C?

> The US-centric problem isn't new to this. I've lost count how many web
> sites can't cope with the fact that I don't have a zip code or that I have
> two middle initials, not one. I'm lucky that I don't have any non-ASCII
> characters in my name; there's a whole nother minefield waiting there.
>  
> Allow me to point you at:
> https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
> https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
> https://wiesmann.codiferes.net/wordpress/?p=15187&lang=en

Comprehensive list of lists:
	https://github.com/kdeldycke/awesome-falsehood

> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
> internally for all timestamps, leaving the leap second mess to the
> periphery.

How does TAI get set given that mostly UTC is distributed and LS need to be
added to get TAI? Or do you mean an arbitrary TAI timescale ignoring LS?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


From guy at alum.mit.edu  Sat Dec 14 09:09:38 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sat, 14 Dec 2019 01:09:38 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191213221336.GE24121@davros.org>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
Message-ID: <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>

On Dec 13, 2019, at 2:13 PM, Clive D.W. Feather <clive at davros.org> wrote:

> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
> internally for all timestamps, leaving the leap second mess to the
> periphery.

Yes, section 5.1.1 "Time" of

	https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634

specifies that the base representation of times is the number of seconds that have elapsed since 1999-12-31T23:59:28 UTC. :-) :-) :-) :-) :-)

(I.e., the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as an instant of time that has more zeroes in the way it's represented as TAI than in the way it's represented as UTC.  If it had been defined as the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC. that would still "leave the leap second mess to the periphery"; it would just mean that the count of seconds would be 32 seconds lower.

By the way, how is TAI, represented as YYYY-MM-DDTHH:MM:SS TAI, defined?  Does it have a Gregorian-style calendar made up entirely of 86400-second days, so that most years are exactly 31,536,000 seconds long, with some years being exactly 31,622,400 seconds long?  If so, then there are at least four different flavors of time stamp, with "time stamp" defined as "label assigned to an instant of time":

	1) "TAI-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, with non-leap years being exactly 31,536,000 seconds long and leap years being exactly 31,622,400 seconds long, so that SS goes from 00 to 59, never to 60;

	2) "UTC-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, but with some years being 31,536,001 seconds, 31,622,401 seconds long, or 31,622,402 seconds long, depending on how many leap seconds there were during the year, so SS could occasionally go from 59 to 60;

	3) counts of seconds since a specified epoch, with the count including leap seconds;

	4) counts of non-leap seconds since a specified epoch.

Note that 3) could use either a TAI-style calendar+clock or a UTC-style calendar+lock to specify the epoch; the same is true of 4).)

From clive at davros.org  Sat Dec 14 09:18:19 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Sat, 14 Dec 2019 09:18:19 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <c432c71d-0d97-767d-7726-3c62d5598047@SystematicSw.ab.ca>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <c432c71d-0d97-767d-7726-3c62d5598047@SystematicSw.ab.ca>
Message-ID: <20191214091819.GA30165@davros.org>

Brian Inglis said:
>> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
>> internally for all timestamps, leaving the leap second mess to the
>> periphery.
> 
> How does TAI get set given that mostly UTC is distributed and LS need to be
> added to get TAI? Or do you mean an arbitrary TAI timescale ignoring LS?

No, that's what I meant by "the periphery".

The management device - perhaps your phone or in a big site one of the
servers - has to know all about time zones and leap seconds. But if you
want 87 lights to turn on at exactly 06:23:45 tomorrow, you don't need
those 87 light bulbs to all have to manage time zone and leap second
tables [1]. The main network just sends out times as TAI/UTC seconds since
an epoch.

[1] This isn't a joke. A major use case for Mesh is controlling lights in a
large building without lots of cables to light switches: the switches can
be little battery-powered things that sit on a desk or are stuck to the
wall.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646


From clive at davros.org  Sat Dec 14 09:23:22 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Sat, 14 Dec 2019 09:23:22 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
Message-ID: <20191214092322.GB30165@davros.org>

Guy Harris said:
>> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
>> internally for all timestamps, leaving the leap second mess to the
>> periphery.
> 
> Yes, section 5.1.1 "Time" of
> 
> 	https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634
> 
> specifies that the base representation of times is the number of seconds that have elapsed since 1999-12-31T23:59:28 UTC. :-) :-) :-) :-) :-)

Yes. But ...

> (I.e., the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as an instant of time that has more zeroes in the way it's represented as TAI than in the way it's represented as UTC.  If it had been defined as the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC. that would still "leave the leap second mess to the periphery"; it would just mean that the count of seconds would be 32 seconds lower.

No, that's not the only way.

> By the way, how is TAI, represented as YYYY-MM-DDTHH:MM:SS TAI, defined?  Does it have a Gregorian-style calendar made up entirely of 86400-second days, so that most years are exactly 31,536,000 seconds long, with some years being exactly 31,622,400 seconds long?

Yes, and that's a big part of "avoiding the mess" - you don't worry about
time zones *or* leap seconds.

> If so, then there are at least four different flavors of time stamp, with "time stamp" defined as "label assigned to an instant of time":
> 
> 	1) "TAI-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, with non-leap years being exactly 31,536,000 seconds long and leap years being exactly 31,622,400 seconds long, so that SS goes from 00 to 59, never to 60;

That's what Mesh uses when handling a "broken-down" time. Hence "TAI".

> 	3) counts of seconds since a specified epoch, with the count including leap seconds;

And that's what Mesh uses when just counting seconds. I agree that it
doesn't matter whether you could TAI seconds or UTC seconds, because
they're exactly the same.

> Note that 3) could use either a TAI-style calendar+clock or a UTC-style calendar+lock to specify the epoch; the same is true of 4).)

True. But that excludes your item 1.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646


From guy at alum.mit.edu  Sat Dec 14 09:57:38 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sat, 14 Dec 2019 01:57:38 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191214092322.GB30165@davros.org>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
Message-ID: <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>

On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:

> Guy Harris said:
>>> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
>>> internally for all timestamps, leaving the leap second mess to the
>>> periphery.
>> 
>> Yes, section 5.1.1 "Time" of
>> 
>> 	https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634
>> 
>> specifies that the base representation of times is the number of seconds that have elapsed since 1999-12-31T23:59:28 UTC. :-) :-) :-) :-) :-)
> 
> Yes. But ...
> 
>> (I.e., the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as an instant of time that has more zeroes in the way it's represented as TAI than in the way it's represented as UTC.  If it had been defined as the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC. that would still "leave the leap second mess to the periphery"; it would just mean that the count of seconds would be 32 seconds lower.
> 
> No, that's not the only way.

What's the other way?

>> By the way, how is TAI, represented as YYYY-MM-DDTHH:MM:SS TAI, defined?  Does it have a Gregorian-style calendar made up entirely of 86400-second days, so that most years are exactly 31,536,000 seconds long, with some years being exactly 31,622,400 seconds long?
> 
> Yes, and that's a big part of "avoiding the mess" - you don't worry about
> time zones *or* leap seconds.

...unless you need to convert a Bluetooth Mesh time stamp to UTC.

And the same would be true if it counted the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC.

>> If so, then there are at least four different flavors of time stamp, with "time stamp" defined as "label assigned to an instant of time":
>> 
>> 	1) "TAI-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, with non-leap years being exactly 31,536,000 seconds long and leap years being exactly 31,622,400 seconds long, so that SS goes from 00 to 59, never to 60;
> 
> That's what Mesh uses when handling a "broken-down" time. Hence "TAI".

Preview doesn't report the word "broken" anywhere in the spec.  The times discussed in 5.1.4.2 Schedule Register presumably are, when no wildcards are involved, local dates/times, with a time stamp being a Gregorian-style YY-MM-DDTHH:MM:SS, and with non-leap years being either 31,536,000, 31,536,001, or 31,536,002 seconds long, and with leap years being either 31,622,400, 31,622,401, or 31,622,402 seconds long (which might disagree with most real-world clocks, as those clocks probably behave as if you had a UTC calendar and a clock that ticks like TAI, in the sense that it always goes from 23:59:59 to 00:00:00, but that's some number of seconds off from TAI).

The Time state includes TAI-UTC Delta Current, TAI-UTC Delta New, and TAI of Delta Change; those require dealing with leap seconds.

>> 	3) counts of seconds since a specified epoch, with the count including leap seconds;
> 
> And that's what Mesh uses when just counting seconds. I agree that it
> doesn't matter whether you could TAI seconds or UTC seconds, because
> they're exactly the same.

I.e., nothing prevents such a clock from

>> Note that 3) could use either a TAI-style calendar+clock or a UTC-style calendar+lock to specify the epoch; the same is true of 4).)
> 
> True. But that excludes your item 1.

3) and 4) both completely exclude 1) and 2) - they're all different schemes for time-stamping instants of time, so 1) excludes 2), 3), and 4), 2) excludes 1), 3), and 4), 3) excludes 1), 2), and 4), and 4) excludes 1), 2) and 3).  For 1) and 2), a time stamp would look like 2019-12-15T09:54:56; for 3) and 4), a time stamp would look like 1576317243.

Both 3) and 4) could use either a 1)-style stamp or a 2)-style stamp in whatever spec defines the epoch.

(The point is that, in a time stamping mechanism that stamps times with counts of seconds since an epoch, whether the count includes leap seconds is independent of whether the specification for the epoch includes the letters "T", "A", and "I" in sequence with no spaces between them or includes the letters "U", "T", and "C" in sequence with no spaces between them.)

From scs at eskimo.com  Sat Dec 14 16:00:48 2019
From: scs at eskimo.com (Steve Summit)
Date: Sat, 14 Dec 2019 11:00:48 -0500
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
Message-ID: <2019Dec14.1100.scs.0003@quinine2.home>

Guy Harris wrote:
> On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:
>> Guy Harris said:
>>> ...the only way in which it "uses TAI" rather than using UTC is that
>>> the epoch is defined as...
>>
>> No, that's not the only way.
>
> What's the other way?

I'm guessing that the other way boils down to (however you try to
represent dates and times) *not* having any leap seconds anywhere
-- that is, unambiguously working in TAI everywhere, and drifting
farther away from UTC every time there's a leap second.

>> Yes, and that's a big part of "avoiding the mess" - you don't
>> worry about time zones *or* leap seconds.
>
> ...unless you need to convert a Bluetooth Mesh time stamp to UTC.

Right.  I imagine that's a pretty big problem.

> The times discussed in 5.1.4.2 Schedule Register presumably are [...]
> with non-leap years being either 31,536,000, 31,536,001, or 31,536,002
> seconds long

I wouldn't presume that at all.  If it's doing TAI, if it's not
counting leap seconds, why would you presume years of other than
31,536,000 or 31,622,400 seconds?

> The point is that, in a time stamping mechanism that stamps times with
> counts of seconds since an epoch, whether the count includes leap
> seconds is independent of whether the specification for the epoch
> includes the letters "T", "A", and "I" ...

There may be additional subtleties here that I'm overlooking,
but to me, this discussion cuts to the heart of the whole eternal
leap second imbroglio.

Guy has, I think, tried to carefully decouple two aspects of the
question:

A. Does your time scale count leap seconds or not, and
B. Does your representation use broken-down times ("calendar +
   clock"), or monotonic counts of seconds since an epoch?

I agree that those issues are orthogonal.  (I'm also going to
ignore for now the side question of whether the epoch mentioned
in "B" is defined as a UTC or TAI timestamp.)

So when Guy said "there are at least four different flavors of
time stamp", I think his flavors map onto my two aspects A and B
with this little truth table:

  A    B
 no   b-d   1) TAI-style calendar+clock
 yes  b-d   2) UTC-style calendar+clock
 no   mono  4) counts of non-leap seconds since a specified epoch
 yes  mono  3) counts of seconds since a specified epoch,
               with the count including leap seconds

Me, I would say that (1) and (4) are completely compatible --
they're two different representations for the same underlying
time scale.  You can perfectly interconvert between them using
the same algorithm Posix defines for time_t.

When it comes to UTC, however, (2) and (3) are most definitely
not compatible.  Personally, I believe that (2) is the *only*
way to represent UTC.  I believe -- Posix time_t most assuredly
notwithstanding -- that (3) is an abomination.

If you try to represent UTC using a monotonic count of seconds,
you have to either (a) ignore leap seconds after all (as Posix
does, but which totally contradicts those words "with the count
including leap seconds" in the definition of (3)), or (b) use
a kludgey and non-obvious (and non-Posix) mapping between your
monotonic time and broken-down calendar+time, a mapping which
always requires you to have a perfect leap second table available.

And in fact, if you try to do (b), I believe that you are *not*
really doing UTC, after all -- you are basically doing TAI
(perhaps with a slightly different epoch), and misleadingly
calling it UTC.  You are engendering just as much confusion as
the Posix time_t definition does.  A monotonic count of seconds
is simply not an appropriate representation for UTC.  The only
proper representation(s) of UTC are those that separate the date
from the time, so that they can cleanly, honestly, openly, and
explicitly accommodate those pesky days of other than 86400
seconds.


From guy at alum.mit.edu  Sat Dec 14 19:23:34 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sat, 14 Dec 2019 11:23:34 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <2019Dec14.1100.scs.0003@quinine2.home>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
Message-ID: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>

On Dec 14, 2019, at 8:00 AM, Steve Summit <scs at eskimo.com> wrote:

> Guy Harris wrote:
>> On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:
>>> Guy Harris said:
>>>> ...the only way in which it "uses TAI" rather than using UTC is that
>>>> the epoch is defined as...
>>> 
>>> No, that's not the only way.
>> 
>> What's the other way?
> 
> I'm guessing that the other way boils down to (however you try to
> represent dates and times) *not* having any leap seconds anywhere
> -- that is, unambiguously working in TAI everywhere, and drifting
> farther away from UTC every time there's a leap second.

Meaning, for example, that the time and date fields in 5.1.4.2 "Schedule Register" represent TAI times rather than local times?

The time stamps described in 5.1.1 "Time" are "type 3" in my list - a count of all elapsed seconds, including leap seconds, since a given epoch.

If you're keeping UTC - not the not-quite-UTC called "POSIX time" - you *also* need a count of all elapsed seconds, including leap seconds, since a given epoch, given that UTC time, like TAI time, changes even during positive leap seconds; it just happens to change in a different way.

In TAI, it always goes, presumably, from {day} 23:59:59 TAI to {next day} 00:00:00 TAI, regardless of whether a positive leap second is inserted at that instant of time or not.

In UTC, it goes from {day} 23:59:59 UTC to {same day} 23:59:60 UTC, and in the *next* second goes to {next day} 00:00:00 UTC.

It's only in times like "POSIX time" where it stays stuck at 23:59:59, or is slowed down, or whatever form of tweaking is done to pretend that every day is 86400 seconds long; that's not done in real UTC.

>>> Yes, and that's a big part of "avoiding the mess" - you don't
>>> worry about time zones *or* leap seconds.
>> 
>> ...unless you need to convert a Bluetooth Mesh time stamp to UTC.
> 
> Right.  I imagine that's a pretty big problem.
> 
>> The times discussed in 5.1.4.2 Schedule Register presumably are [...]
>> with non-leap years being either 31,536,000, 31,536,001, or 31,536,002
>> seconds long
> 
> I wouldn't presume that at all.  If it's doing TAI, if it's not
> counting leap seconds, why would you presume years of other than
> 31,536,000 or 31,622,400 seconds?

Because, in that section, it's *not* doing TAI:

	5.1.4.2 Schedule Register

	The Schedule Register state is a 16-entry, zero-based, indexed array of 76-bit values formatted as Scheduled Time. Each entry represents a state-changing event. *Time and date fields represent local time.*

> 
>> The point is that, in a time stamping mechanism that stamps times with
>> counts of seconds since an epoch, whether the count includes leap
>> seconds is independent of whether the specification for the epoch
>> includes the letters "T", "A", and "I" ...
> 
> There may be additional subtleties here that I'm overlooking,
> but to me, this discussion cuts to the heart of the whole eternal
> leap second imbroglio.
> 
> Guy has, I think, tried to carefully decouple two aspects of the
> question:
> 
> A. Does your time scale count leap seconds or not, and
> B. Does your representation use broken-down times ("calendar +
>   clock"), or monotonic counts of seconds since an epoch?

What does "count leap seconds" mean in this context?

If you have a B-style representation, it means "does that count increase during a positive leap second?" (we'll ignore negative leap seconds here).

If you have an A-style representation, and it's TAI or UTC, it "counts leap seconds" in the sense that "the clock value changes even for the leap second and, if it overflows, the calendar value changes as well".  The difference between TAI and UTC in that regard is in the fashion in which the clock value changes.  The clock value changes in the same fashion, all the time, in TAI; it doesn't change in the same fashion, all the time, in UTC, *and the way in which it will change in the future is not predictable past a certain point* - you have to wait for an IERS Bulletin C to come out for that point before you can predict.

So are A-style representations defined for both UTC and TAI?  ITU-R Recommendation TF.460-6 says:

	2 Leap-seconds

	2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September.

	2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex 3).

but where 1) the form HHh Mmm SSs for time stamps specified for UTC, 2) is that also specified for TAI?, 3) is it stated anywhere how days are indicated in this context (YYYY-MM-DD?  DD MMMMM YYYY?)

What that Recommendation says is

	B International atomic time (TAI)

	The international reference scale of atomic time (TAI), based on the second (SI), as realized on the rotating geoid, is formed by the BIPM on the basis of clock data supplied by cooperating establishments. It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 (adopted by the CGPM 1971).

	C Coordinated universal time (UTC)

	UTC is the time-scale maintained by the BIPM, with assistance from the IERS, which forms the basis of a coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI but differs from it by an integer number of seconds.

	The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leap-seconds) to ensure approximate agreement with UT1.

which, at most, says that, *for example*, TAI is in the form of days (presumably days that are always exactly 86400 seconds long)), hours. minutes, and seconds from "the origin 1 January 1958" (does that mean "midnight, 1 January 1958"?).  If, in fact, "days" correspond to exactly-86400-second-long days, and "the origin 1 January 1958" is "midnight, 1 January 1958", TAI could also be represented as a scale of seconds since the origin 1 January 1958, with conversion between those two scales being straightforward (division and remainder to go from the second scale to the first, multiplication and addition to go from the first scale to the second, given that there are no leap seconds, month lengths, or leap years to worry about).

Can TAI also be represented as an absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day?  If so, are there any specified rules for that?  (Conversion to or from that scale from either of the scales mentioned in the previous paragraph is a little more work, as you'd have to worry about month lengths and leap years).

And in what ways could the UTC scale be represented?  The "differs from it by an integral number of seconds", with the difference varying over time, would presumably be a difference between the "absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day" representations of TAI or UTC, given that "It corresponds exactly in rate with TAI" means that, for the "days, hours, minutes and seconds from the origin 1 January 1958" definition of TAI, every one of those seconds occurs in UTC as well, so if you represent UTC as a count of days, hours, minutes, and seconds from some origin, or just as a count of seconds from that origin, the difference between the two scales, in seconds, is the difference between the origins, in seconds.

Annex 3 of that recommendation, "Dating of events in the vicinity of a leap-second", shows events being dated "30 June, 23h 59m 60.6s UTC"; as it's an example, the year is omitted, so presumably the "30 June" would have a year number after it for a real event, i.e. an absolute Gregorian-style date.

> Me, I would say that (1) and (4) are completely compatible --
> they're two different representations for the same underlying
> time scale.  You can perfectly interconvert between them using
> the same algorithm Posix defines for time_t.
> 
> When it comes to UTC, however, (2) and (3) are most definitely
> not compatible.  Personally, I believe that (2) is the *only*
> way to represent UTC.  I believe -- Posix time_t most assuredly
> notwithstanding -- that (3) is an abomination.

(2) and (3) are both problematic.

With (2), time stamps for events defined to occur at a specified sufficiently large number of seconds in the future cannot be predicted.  That includes all events with times specified by a (1)-style or (4)-style time stamp if those times go past what the IERS has specified.

With (3), some time stamps cannot be specified - including time stamps for events in the *past*, such as an event occurring on 30 June 2015 at 23h 59m 60s UTC.

> If you try to represent UTC using a monotonic count of seconds,
> you have to either (a) ignore leap seconds after all (as Posix
> does, but which totally contradicts those words "with the count
> including leap seconds" in the definition of (3)), or (b) use
> a kludgey and non-obvious (and non-Posix) mapping between your
> monotonic time and broken-down calendar+time, a mapping which
> always requires you to have a perfect leap second table available.
> 
> And in fact, if you try to do (b), I believe that you are *not*
> really doing UTC, after all -- you are basically doing TAI
> (perhaps with a slightly different epoch), and misleadingly
> calling it UTC.

If you are doing (a), you're not doing UTC either, given that POSIX can't distinguish between, say, 30 June 2015, 23h 59m 59s UTC and 30 June 2015, 23h 59m 60s UTC.

(a) can't even do UTC correctly for *past* events.  (b) *can* do UTC correctly for past events if you have a leap second table available that includes all announced leap seconds as of now - I think there may even be some sample code to do that. :-)  What it can't do is handle UTC for *future* events, as a "perfect" leap second table requires perfect knowledge of the future, and we all what somebody (Karl Kristian Steincke?) said about predicting:

	http://quoteinvestigator.com/2013/10/20/no-predict/

TLDR: "you can't do UTC for arbitrary times in the future without running the risk of having to adjust something before the event".  (Well, with sufficient thiotimoline used in your clock you might. :-))

> You are engendering just as much confusion as
> the Posix time_t definition does.  A monotonic count of seconds
> is simply not an appropriate representation for UTC.  The only
> proper representation(s) of UTC are those that separate the date
> from the time, so that they can cleanly, honestly, openly, and
> explicitly accommodate those pesky days of other than 86400
> seconds.

You cannot predict what the broken-down UTC label for an event N seconds in the future will be, if N is sufficiently large that it will be past a point at which a leap second might be introduced and for which the IERS hasn't announced whether there will be a leap second or not - the UTC label depends on whether a leap second will be inserted there or not.

So UTC - and local civil time, if based on UTC - isn't a good way to label events sufficiently far in the future (as in, right now, any event happening at or after the end of 30 June 2020), if you can't live with being a few seconds off.

So if we want to describe *any* timekeeping scheme that represents times in a format that is, or can trivially be converted to and from without loss of information, a count of seconds, including leap seconds, since some epoch, as "TAI", OK.  That does *not*, of course, mean that the epoch needs to be expressed as a TAI time stamp; "seconds, including leap seconds, since 1970-01-01 00:00:00 UTC" would then be a representation of TAI (given that we know what instant of time was labeled 1970-01-01 00:00:00 UTC - no knowledge of the future is needed there).

From kre at munnari.OZ.AU  Sun Dec 15 00:04:04 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Sun, 15 Dec 2019 07:04:04 +0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
Message-ID: <1667.1576368244@jinx.noi.kre.to>

The problem we have in the current discussion, is that once again,
we're trying to over simplify time - make time work the way we think
it should work, rather than the way it does.

It makes no sense (to me) at all to convert TAI into any kind of
(currently used) calendar type measurements - the calendars we use
are designed to match astronomical reality (the various rotations of
the earth) and those things just don't take constant periods, even
though they're close.   But that's what we have decided we want from
our calendar system - we want it to alwqays be summer in January, and
winter in July (those unfortunate enough to be in the wrong hemisphere
can adapt as needed), and TAI (alone, withough some kinds of
corrections) simply does not provide that.   If you want some kind of
calendar for TAI you'd be better to convert it to stardates or something.

Certainly I don't think it makes any rational sense to have different
length "years" (regular years and leap years, with a bizarre rule about
which years are which) in TAI - though it is certainly sensible to have a
unit bigger than seconds in which to measure lengthy periods (though I doubt
anything approximating a year is really big enough - TAI is useful for
measuring short durations (something we would conventionally count in
tiny fractions of a second up to hours), and very long ones (millions of
years, and longer), but not so much for anything in between).

What we really need to do is recognise that there is not (rather should
not be) just one definition (one unit) "a second" - there are two entirely
different things we use commonly, which just happen to be so close together
that we have tried to force them to be the same thing.

One is the thing TAI uses (and UTC with leap second corrections) - which is
a period defined by something that we believe to be fixed - always the exact
same duration, and so can be used for comparing durations from measurements
collected separately,

The other is 1/84600 of a day (a bizarre choice, but never mind) where a
day is defined according to the (varying) rotations of the earth, and hence
the second is not a fixed length, but a variable one.   That's the POSIX
second (time_t) value, but is also how humans have measured time ever since
we started doing it - initially it wasn't understood that the length of a
day wasn't constant (as it so nearly is) but 60 seconds a minute, 60
minutes an hour, 24 hours a day, (ie: 86400 seconds a day) is what has been
used for a long time now, (with the more precise measurements appearing as
we gained the ability to measure them, sundials to be able to measure house,
hourglasses to meaure minutes, and fractions thereof somtimes, ...)

We really should be using two different names for these two different things,
rather than trying to pretend that a "second" can be defined which suits
both purposes.

But until a large enough fraction of the population need to routinely
deal with the differences, I don't see that happening.   Certainly it
doesn't help to continually try and force one another to adopt only one
way of measuring time, as there is (as long as we keep anything like our
current calendars) no way to make that work simply - nothing anyone would
be prepared to attempt to implement - that is even if one can accept that
any current calendar calculations are even close to simple.

kre



From scs at eskimo.com  Sun Dec 15 00:56:42 2019
From: scs at eskimo.com (Steve Summit)
Date: Sat, 14 Dec 2019 19:56:42 -0500
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <1667.1576368244@jinx.noi.kre.to>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <1667.1576368244@jinx.noi.kre.to>
Message-ID: <2019Dec14.1956.scs.0008@quinine2.home>

Robert Elz wrote:
> It makes no sense (to me) at all to convert TAI into any kind of
> (currently used) calendar type measurements -

Fair enough.

> Certainly I don't think it makes any rational sense to have different
> length "years" (regular years and leap years, with a bizarre rule about
> which years are which) in TAI - though it is certainly sensible to have
> a unit bigger than seconds in which to measure lengthy periods...

Vernor Vinge has a wonderful set of SF novels ("A Deepness in the
Sky", etc.), set in the far future, in which they measure time in
kiloseconds, megaseconds, etc.  There's also this marvelous
passage concerning legacy software:

	Via a million million circuitous threads of inheritance,
	many of the oldest programs still ran in the bowels of
	the Qeng Ho system.  Take the Traders' method of timekeeping.
	The frame corrections were incredibly complex -- and down
	at the very bottom of it was a little program that ran a
	counter.  Second by second, the Qeng Ho counted time from
	the instant that a human had first set foot on Old Earth's
	moon.  But if you looked at it still more closely...
	the starting instant was actually about fifteen million
	seconds later, the 0-second of one of Humankind's first
	computer operating systems.

> What we really need to do is recognise that there is not [...] just one
> definition (one unit) "a second" - there are two entirely different
> things we use commonly [...] One is the thing TAI uses [...] The other
> is 1/84600 of a day [...] where a day is defined according to the
> (varying) rotations of the earth, and hence the second is not a fixed
> length, but a variable one.  That's the POSIX second (time_t) value [...]

I don't entirely disagree, and indeed bringing UT1 to bear is an
attractive way of trying to rescue the benighted Posix definition,
but time_t is certainly not defined that way now, and I'm not aware
of anyone implementing it that way!  time_t seconds really are
UTC/TAI seconds (except, of course, when they're not).

[But perhaps what you're saying is that redefining time_t as UT1
is part of "What we really need to do".]


From kre at munnari.OZ.AU  Sun Dec 15 05:16:46 2019
From: kre at munnari.OZ.AU (Robert Elz)
Date: Sun, 15 Dec 2019 12:16:46 +0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <2019Dec14.1956.scs.0008@quinine2.home>
References: <2019Dec14.1956.scs.0008@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
Message-ID: <28493.1576387006@jinx.noi.kre.to>

    Date:        Sat, 14 Dec 2019 19:56:42 -0500
    From:        scs at eskimo.com (Steve Summit)
    Message-ID:  <2019Dec14.1956.scs.0008 at quinine2.home>

  | [But perhaps what you're saying is that redefining time_t as UT1
  | is part of "What we really need to do".]

First, part ofmy belief is that nothing that POSIX (or the C std)
has related to time is even close to adequate.

For time_t what I mean is that it should not survive as it is, we need
(just for "seconds" time counters) two entirely different things,  which
keep track of the different ways we count time, differently.  Currently
this is fudged with how one obtains the time_t (CLOCK_MONOTONIC, CLOCK_REALTIME
etc) but because they all produce the same type (time_t) they can all
be processed the same way - so a CLOCK_MONOTONIC result can be handed to 
localtime() which makes no rational sense at all.

kre



From john.haxby at oracle.com  Sun Dec 15 13:03:44 2019
From: john.haxby at oracle.com (John Haxby)
Date: Sun, 15 Dec 2019 13:03:44 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <28493.1576387006@jinx.noi.kre.to>
References: <2019Dec14.1956.scs.0008@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <28493.1576387006@jinx.noi.kre.to>
Message-ID: <926A7281-FDB4-49CC-8A85-7B55AF7DB65D@oracle.com>



> On 15 Dec 2019, at 05:16, Robert Elz <kre at munnari.OZ.AU> wrote:
> 
>    Date:        Sat, 14 Dec 2019 19:56:42 -0500
>    From:        scs at eskimo.com (Steve Summit)
>    Message-ID:  <2019Dec14.1956.scs.0008 at quinine2.home>
> 
>  | [But perhaps what you're saying is that redefining time_t as UT1
>  | is part of "What we really need to do".]
> 
> First, part ofmy belief is that nothing that POSIX (or the C std)
> has related to time is even close to adequate.
> 
> For time_t what I mean is that it should not survive as it is, we need
> (just for "seconds" time counters) two entirely different things,  which
> keep track of the different ways we count time, differently.  Currently
> this is fudged with how one obtains the time_t (CLOCK_MONOTONIC, CLOCK_REALTIME
> etc) but because they all produce the same type (time_t) they can all
> be processed the same way - so a CLOCK_MONOTONIC result can be handed to 
> localtime() which makes no rational sense at all.
> 
> kre
> 

I completely agree.  IIRC, Posix defines the time returned by various things as "since approximately 1970-01-01 00:00:00 UTC" or "since an undefined epoch".   Basically, the first time_t roughly gives the current wall-clock time in the Greenwich observatory in northern hemisphere winter (you can offset it to whatever timezone you think you are in).   The second time_t gives you a reliable way of measuring elapsed time[1].

The central assumption of posix time-of-day is that a day is exactly 86400 seconds which is handy if you're doing quick and dirty coding: but how long does sleep(86400) sleep for over a leap second?  (There are good, bad and ugly possible answers.  And accurate ones.).

I think Go has the right idea.   A time.Time object works for both elapsed and wall-clock time by holding two possible values.   So when there's been a leap second, noon-to-noon should show an elapsed time of 86401 seconds (I wonder if it does?) and if you want to sleep() from noon to noon you need to sleep the calculated interval, not 86400.

It's a mess.

jch



[1] a certain database is, finally, using that to measure elapsed time.

From michael.h.deckers at googlemail.com  Sun Dec 15 13:22:55 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Sun, 15 Dec 2019 13:22:55 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <1667.1576368244@jinx.noi.kre.to>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
Message-ID: <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>


 ?? On 2019-12-15 00:04, Robert Elz wrote:

> It makes no sense (to me) at all to convert TAI into any kind of
> (currently used) calendar type measurements - the calendars we use
> are designed to match astronomical reality (the various rotations of
> the earth) and those things just don't take constant periods, even
> though they're close.   But that's what we have decided we want from
> our calendar system - we want it to alwqays be summer in January, and
> winter in July (those unfortunate enough to be in the wrong hemisphere
> can adapt as needed), and TAI (alone, withough some kinds of
> corrections) simply does not provide that.   If you want some kind of
> calendar for TAI you'd be better to convert it to stardates or something.


 ??? The notation of values of TAI using the Gregorian calendar is helpful
 ??? when comparing time scales. For instance, in the recent BIPM definition
 ??? of TAI, as sanctioned by the 26th CGPM 2018, online at
 ??? [https://www.bipm.org/en/CGPM/db/26/2/], we read:

 ??????? "TT - TAI = 32.184 s exactly at 1 January 1977, 0h TAI
 ???????? at the geocentre, in order to ensure continuity
 ???????? of TT with Ephemeris Time"


> ....
> What we really need to do is recognise that there is not (rather should
> not be) just one definition (one unit) "a second" - there are two entirely
> different things we use commonly, which just happen to be so close together
> that we have tried to force them to be the same thing.
>
> One is the thing TAI uses (and UTC with leap second corrections) - which is
> a period defined by something that we believe to be fixed - always the exact
> same duration, and so can be used for comparing durations from measurements
> collected separately,
>
> The other is 1/84600 of a day (a bizarre choice, but never mind) where a
> day is defined according to the (varying) rotations of the earth, and hence
> the second is not a fixed length, but a variable one.   That's the POSIX
> second (time_t) value, but is also how humans have measured time ever since
> we started doing it - initially it wasn't understood that the length of a
> day wasn't constant (as it so nearly is) but 60 seconds a minute, 60
> minutes an hour, 24 hours a day, (ie: 86400 seconds a day) is what has been
> used for a long time now, (with the more precise measurements appearing as
> we gained the ability to measure them, sundials to be able to measure house,
> hourglasses to meaure minutes, and fractions thereof somtimes, ...)
>
> We really should be using two different names for these two different things,
> rather than trying to pretend that a "second" can be defined which suits
> both purposes.


 ??? I disagree.

 ??? You are right that the time scales UT1 and TAI have different 
rates; and
 ??? there are several other time scales used in astronomy (eg TCB, TCG, 
TDB)
 ??? with still other rates. This is caused by physics (not just by the
 ??? tradition of mean solar time derived from Earth rotation).

 ??? Astronomers want to be able to compare these time scales and convert
 ??? between them, hence they _must_ express their values in common units.
 ??? Even the mere expression that the time scales differ in rate requires
 ??? the use of common units.

 ??? For instance, the differential quotient d(TAI - UT1)/d(UT1) is a
 ??? measure of the speed of rotation of the Earth called "excess length
 ??? of day" (it actually was negative, -20 ?s/d on 2019-12-11).
 ??? We cannot compute TAI - UT1 unless the values of TAI and UT1 are
 ??? expressed in the same units. Still another non-SI time unit would
 ??? only confuse the issue.

 ??? Beyond that, the quantity "mean solar second" = d(TAI)/d(UT1)?(1 s)
 ??? would be a bad choice for a unit since d(TAI)/d(UT1) changes
 ??? unpredictably over time.

 ??? In the presence of different time scales, it certainly is necessary
 ??? to designate the time scale in which a specific datetime was
 ??? observed; in ISO 8601 notation, the suffix Z indicates a UTC value,
 ??? a suffixed offset indicates a local civil time scale derived from
 ??? UTC; and otherwise, an appended time scale acronym (as above) is
 ??? often used to indicate the time scale.

 ??? Michael Deckers.



From Brian.Inglis at SystematicSw.ab.ca  Sun Dec 15 23:52:25 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Sun, 15 Dec 2019 16:52:25 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <2019Dec14.1956.scs.0008@quinine2.home>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <2019Dec14.1956.scs.0008@quinine2.home>
Message-ID: <1de2e8e4-3df0-8098-670f-787a8eb62ea3@SystematicSw.ab.ca>


On 2019-12-14 17:56, Steve Summit wrote:
> Vernor Vinge has a wonderful set of SF novels ("A Deepness in the
> Sky", etc.), set in the far future, in which they measure time in
> kiloseconds, megaseconds, etc.  There's also this marvelous
> passage concerning legacy software:

> Via a million million circuitous threads of inheritance, many of the oldest
> programs still ran in the bowels of the Qeng Ho system.  Take the Traders'
> method of timekeeping. The frame corrections were incredibly complex -- and
> down at the very bottom of it was a little program that ran a counter.
> Second by second, the Qeng Ho counted time from the instant that a human had
> first set foot on Old Earth's moon.  But if you looked at it still more
> closely... the starting instant was actually about fifteen million seconds
> later, the 0-second of one of Humankind's first computer operating systems.

Should not make assumptions about other cultures, as they may be upset.
Now, would more likely have been 1.5 billion seconds later:

$ TZ=UTC date -d 2019-01-03\ 02:26 +%s # Chang'e 4 landing
1546482360

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


From Brian.Inglis at SystematicSw.ab.ca  Mon Dec 16 00:08:04 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Sun, 15 Dec 2019 17:08:04 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <1de2e8e4-3df0-8098-670f-787a8eb62ea3@SystematicSw.ab.ca>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <2019Dec14.1956.scs.0008@quinine2.home>
 <1de2e8e4-3df0-8098-670f-787a8eb62ea3@SystematicSw.ab.ca>
Message-ID: <46715fcb-4c80-0da3-9cef-15c9858420ec@SystematicSw.ab.ca>

On 2019-12-15 16:52, Brian Inglis wrote:
> Should not make assumptions about other cultures, as they may be upset.
[Upset meaning rendered incorrect rather than feeling annoyed.]
> Now, would more likely have been 1.5 billion seconds later:
> $ TZ=UTC date -d 2019-01-03\ 02:26 +%s # Chang'e 4 landing
> 1546482360

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


From eggert at cs.ucla.edu  Mon Dec 16 00:53:06 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Sun, 15 Dec 2019 16:53:06 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <1667.1576368244@jinx.noi.kre.to>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
Message-ID: <21e3e0f0-2b83-3414-9ed6-40e7c5572259@cs.ucla.edu>

On 12/14/19 4:04 PM, Robert Elz wrote:
> It makes no sense (to me) at all to convert TAI into any kind of
> (currently used) calendar type measurements - the calendars we use
> are designed to match astronomical reality

Well, sort of. Astronomers normally match astronomical reality only by using the
technology of 45 BC, because they define a "year" to be the Julian year (31.5576
Ms) when, for example, they estimate the Big Bang as being 13.798 ? 0.037
billion years ago. Paleontologists are similar. Archaelogists too, I expect (at
least for anything more than a few centuries old).

For the Big Bang estimate, the difference between Julian and Gregorian is less
than the confidence interval, so the distinction doesn't matter much. It's like
when someone says "a million years ago", they don't much care whether this means
a million years before 2019 or a million years before 2020.

If we wanted to stick to "astronomical reality" it would not be a good idea to
count Earth days, as the length of the Earth day was only four hours or so back
when the the Earth was formed (at least, according to estimates by Takanori
Sasaki <http://www.iea.usp.br/en/news/when-a-day-lasted-only-four-hours>). We'd
be better off counting Earth years, as the length of Earth's year hasn't changed
as much since then. Of course even then our clocks would go back only 4.5
billion years ago, and would stray a bit from astronomical years for other
relatively-minor reasons (such as, the Sun's mass is constantly declining
slightly, which means the Earth year length is constantly growing slightly).


From guy at alum.mit.edu  Mon Dec 16 03:49:40 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sun, 15 Dec 2019 19:49:40 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <28493.1576387006@jinx.noi.kre.to>
References: <2019Dec14.1956.scs.0008@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <28493.1576387006@jinx.noi.kre.to>
Message-ID: <EF159889-A6B3-4DE0-AA6F-DD7783752828@alum.mit.edu>

On Dec 14, 2019, at 9:16 PM, Robert Elz <kre at munnari.OZ.AU> wrote:

> For time_t what I mean is that it should not survive as it is, we need
> (just for "seconds" time counters) two entirely different things,  which
> keep track of the different ways we count time, differently.  Currently
> this is fudged with how one obtains the time_t (CLOCK_MONOTONIC, CLOCK_REALTIME
> etc) but because they all produce the same type (time_t) they can all
> be processed the same way - so a CLOCK_MONOTONIC result can be handed to 
> localtime() which makes no rational sense at all.

For the purposes of logging events as they happen (meaning that, assuming the clock isn't incorrectly set ahead, all time stamps quickly become time stamps in the past), a value that 1) is a count of seconds (and perhaps fractional seconds) that have elapsed since some defined epoch, including leap seconds, and 2) can be converted to YYYY-MM-DD HH:MM:SS.SSSS is useful.

That way, 1) you can easily calculate time deltas between those events and 2) you can find out when a particular event happened.

(Some may already have guessed that I'm thinking of, among other things, network traffic captures here.)

From guy at alum.mit.edu  Mon Dec 16 03:57:23 2019
From: guy at alum.mit.edu (Guy Harris)
Date: Sun, 15 Dec 2019 19:57:23 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
Message-ID: <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>

On Dec 15, 2019, at 5:22 AM, Michael H Deckers <michael.h.deckers at googlemail.com> wrote:

>     The notation of values of TAI using the Gregorian calendar is helpful
>     when comparing time scales.

So how is that defined?

Do you just take a UTC value for the same instant, add the current TAI - UTC delta to it - and, for overflow (meaning "resulting seconds > 59 or minutes > 59 or...), "carry into" the calendar date, so that an event that took place at the end of 2018, with a UTC label, took place at the beginning of 2019, with a TAI label?


From michael.h.deckers at googlemail.com  Mon Dec 16 13:43:56 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Mon, 16 Dec 2019 13:43:56 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
References: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home> <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
 <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
Message-ID: <39682719-ac09-47ba-a921-1e92026c1bc8@googlemail.com>


On 2019-12-16 03:57, Guy Harris wrote:
> On Dec 15, 2019, at 5:22 AM, Michael H Deckers <michael.h.deckers at googlemail.com> wrote:
>
>>      The notation of values of TAI using the Gregorian calendar is helpful
>>      when comparing time scales.
> So how is that defined?
>
> Do you just take a UTC value for the same instant, add the current TAI - UTC delta to it - and, for overflow (meaning "resulting seconds > 59 or minutes > 59 or...), "carry into" the calendar date, so that an event that took place at the end of 2018, with a UTC label, took place at the beginning of 2019, with a TAI label?


 ?? Yes. If TAI was 1977-01-01, then TAI - UTC was 15 s, so that
 ?? UTC was 1977-01-01 - 15 s = 1976-12-31T23:59:45.

 ?? A calendar date just denotes a point on the time axis; and
 ?? a time scale assigns a point on the time axis to each point
 ?? of a region of spacetime (on which the time scale is defined).

 ????? That is a "time scale" in the astronomical sense of the word,
 ????? where TCB, TCG, TDB, TT, UTC, UT1, UT2, and local civil times
 ????? are time scales. A "geological time scale" is something else;
 ????? IEC 60050 has additional meanings for "time scale".

 ?? A calendar is not restricted to the notation of values of one
 ?? specific time scale, and points on the time axis can also be
 ?? denoted by other means: the notations
 ?????? 2000-01-01,
 ?????? JD 2451 544.5
 ?????? MJD 40 587 + 946 684 800 s
 ?????? -50 a B.P.
 ?? all denote the same point on the time axis.

 ?? Michael Deckers.



From clive at davros.org  Mon Dec 16 14:10:21 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 14:10:21 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
References: <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
 <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
Message-ID: <20191216141021.GD490@davros.org>

Guy Harris said:
>>     The notation of values of TAI using the Gregorian calendar is helpful
>>     when comparing time scales.
> 
> So how is that defined?
> 
> Do you just take a UTC value for the same instant, add the current TAI - UTC delta to it - and, for overflow (meaning "resulting seconds > 59 or minutes > 59 or...), "carry into" the calendar date, so that an event that took place at the end of 2018, with a UTC label, took place at the beginning of 2019, with a TAI label?

No.

You take a Gregorian calendar (by default; in principle you could use
Julian or something else) and use it to count *all* SI seconds, so that
every day has exactly 86400 seconds in it. It works the same way as UT1,
but without the unpredictable-length "seconds".

You can convert that to UTC by subtracting the relevant (not "current")
TAI-UTC delta and doing correct carries, remembering to handle the edge
cases when the delta changes.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646


From clive at davros.org  Mon Dec 16 14:36:11 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 14:36:11 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
Message-ID: <20191216143611.GE490@davros.org>

Guy Harris said:
> On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:
> 
> > Guy Harris said:
> >>> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
> >>> internally for all timestamps, leaving the leap second mess to the
> >>> periphery.
> >> 
> >> Yes, section 5.1.1 "Time" of
> >> 
> >> 	https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634

It's a while since I was involved in Mesh, and it's possible that they've
managed to mess things up since then. But, let's see ...

> >> specifies that the base representation of times is the number of seconds that have elapsed since 1999-12-31T23:59:28 UTC. :-) :-) :-) :-) :-)
> > 
> > Yes. But ...
> > 
> >> (I.e., the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as an instant of time that has more zeroes in the way it's represented as TAI than in the way it's represented as UTC.  If it had been defined as the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC. that would still "leave the leap second mess to the periphery"; it would just mean that the count of seconds would be 32 seconds lower.

Okay, that statement does indeed pick a convenient epoch for counting
seconds. It means the the function to map the 40-bit seconds count (and 8
bit subsecond count) to a "broken-down" time in TAI is easy.

>>> By the way, how is TAI, represented as YYYY-MM-DDTHH:MM:SS TAI, defined?  Does it have a Gregorian-style calendar made up entirely of 86400-second days, so that most years are exactly 31,536,000 seconds long, with some years being exactly 31,622,400 seconds long?
>> Yes, and that's a big part of "avoiding the mess" - you don't worry about
>> time zones *or* leap seconds.
> ...unless you need to convert a Bluetooth Mesh time stamp to UTC.

Which is done "on the periphery". Note the use of zero in various fields to
indicate that the device doesn't have zone or leap second information.

> And the same would be true if it counted the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC.

Also true, but it seems cleaner to have the epoch be a round point in TAI,
rather than in UTC, given that you're using TAI internally. Note the
following paragraph:

"To allow Mesh devices to refer to UTC or local times, devices need to be
aware of the past, present, and predicted changes to the TAI-UTC Delta (the
number of seconds between TAI and UTC) and to the local time zone offset
(e.g., in Seattle, USA, the local time is exactly 7 hours behind UTC for
part of the year and 8 hours behind UTC for the rest of the year). Because
these two values can change at any time for physical or political reasons,
they are not hard-coded into this specification. Instead, they are
communicated to all nodes in the mesh provided that at least one device has
the information."

More "periphery" stuff, since most uses won't use those offsets.

An algorithm is also given for converting TAI seconds since the epoch to a
UTC "broken-down" time. Setting E and F to zero will give you a TAI
"broken-down" time.

>>> 	1) "TAI-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, with non-leap years being exactly 31,536,000 seconds long and leap years being exactly 31,622,400 seconds long, so that SS goes from 00 to 59, never to 60;
> > 
>> That's what Mesh uses when handling a "broken-down" time. Hence "TAI".
> 
> Preview doesn't report the word "broken" anywhere in the spec.

The term "broken-down time" is common - or, at least, I thought it was - to
refer to the "YYYY-MM-DD hh:mm:ss" format as opposed to "(some) (sort-of)
seconds past the epoch".

But it's possible that they stopped doing this after I stopped being
involved.

> The times discussed in 5.1.4.2 Schedule Register presumably are, when no wildcards are involved, local dates/times, with a time stamp being a Gregorian-style YY-MM-DDTHH:MM:SS, and with non-leap years being either 31,536,000, 31,536,001, or 31,536,002 seconds long, and with leap years being either 31,622,400, 31,622,401, or 31,622,402 seconds long (which might disagree with most real-world clocks, as those clocks probably behave as if you had a UTC calendar and a clock that ticks like TAI, in the sense that it always goes from 23:59:59 to 00:00:00, but that's some number of seconds off from TAI).

The Scheduler is part of the app you run on your phone, or whatever. As it
says, the fields are in local time.

> The Time state includes TAI-UTC Delta Current, TAI-UTC Delta New, and TAI of Delta Change; those require dealing with leap seconds.

But those are only generated by the device that knows them and are only
used to present values in local time or to convert local time to SI seconds
past the epoch. Most devices in the mesh don't do that.

The Scheduler app converts the local times into TAI-past-the-epoch to send
out "turn on at this time" messages.

> >> 	3) counts of seconds since a specified epoch, with the count including leap seconds;
> > 
> > And that's what Mesh uses when just counting seconds. I agree that it
> > doesn't matter whether you could TAI seconds or UTC seconds, because
> > they're exactly the same.

s/could/call them/

In fact, "SI seconds" might have been better. One reason for using "TAI"
rather than "UTC" is that it makes it clear that all seconds are included
rather than the Posix perversion of calling it UTC and then ignoring some
of them.

> (The point is that, in a time stamping mechanism that stamps times with counts of seconds since an epoch, whether the count includes leap seconds is independent of whether the specification for the epoch includes the letters "T", "A", and "I" in sequence with no spaces between them or includes the letters "U", "T", and "C" in sequence with no spaces between them.)

True, *if* people don't misunderstand.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646


From clive at davros.org  Mon Dec 16 14:56:03 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 14:56:03 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <2019Dec14.1100.scs.0003@quinine2.home>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
Message-ID: <20191216145603.GF490@davros.org>

Steve Summit said:
>> The times discussed in 5.1.4.2 Schedule Register presumably are [...]
>> with non-leap years being either 31,536,000, 31,536,001, or 31,536,002
>> seconds long
> 
> I wouldn't presume that at all.  If it's doing TAI, if it's not
> counting leap seconds, why would you presume years of other than
> 31,536,000 or 31,622,400 seconds?

Those ones are in local time, so have years of varying lengths (*cough*
1751 and 1752 *cough*).

> Guy has, I think, tried to carefully decouple two aspects of the
> question:
> 
> A. Does your time scale count leap seconds or not, and

This depends on what you mean by a leap second. And that is part of the
problem.

> B. Does your representation use broken-down times ("calendar +
>    clock"), or monotonic counts of seconds since an epoch?
>
> I agree that those issues are orthogonal.  (I'm also going to
> ignore for now the side question of whether the epoch mentioned
> in "B" is defined as a UTC or TAI timestamp.)

No. They look orthogonal at first glance, but they aren't.

> So when Guy said "there are at least four different flavors of
> time stamp", I think his flavors map onto my two aspects A and B
> with this little truth table:
> 
>   A    B
>  no   b-d   1) TAI-style calendar+clock
>  yes  b-d   2) UTC-style calendar+clock
>  no   mono  4) counts of non-leap seconds since a specified epoch
>  yes  mono  3) counts of seconds since a specified epoch,
>                with the count including leap seconds

[I'm wondering if that intended to have 3 before 4, based on the following
text.]

What I would have is, rather, the following:

C: Does your time scale count every second exactly once? A "no" answer
means that some seconds are not counted or are counted twice.
D: Does your time scale:
   (1) use a monotonic count of seconds since some epoch
   (2) use a broken-down style with the seconds field always stepping from
       59 to 00 at the end of the minute
   (3) use a broken-down style with the seconds field stepping from 58,
       59, or 60 to 00 at the end of the minute, depending on the exact
       date-time.

C yes D 1 is a count of SI seconds since the epoch. I called it a count of
TAI seconds to avoid people confusing it with:

C no  D 1, which is Posix time_t and which some people erroneously think is
a count of UTC seconds since the epoch. (It is approximately a count of UT1
seconds since the epoch, but I don't want to get into the SI versus sideral
seconds debate).

C yes D 2 is TAI broken-down format.

C no  D 2 is Posix broken-down format.

C yes D 3 is UTC broken-down format.

C no  D 3 is, I hope, never used.

> Me, I would say that (1) and (4) are completely compatible --
> they're two different representations for the same underlying
> time scale.  You can perfectly interconvert between them using
> the same algorithm Posix defines for time_t.

That algorithm can convert between D 1 and D 2 for either C case, so long
as you don't mix them up.

> When it comes to UTC, however, (2) and (3) are most definitely
> not compatible.  Personally, I believe that (2) is the *only*
> way to represent UTC.  I believe -- Posix time_t most assuredly
> notwithstanding -- that (3) is an abomination.

UTC is C yes D 3.

> If you try to represent UTC using a monotonic count of seconds,
> you have to either (a) ignore leap seconds after all (as Posix
> does, but which totally contradicts those words "with the count
> including leap seconds" in the definition of (3)), or (b) use
> a kludgey and non-obvious (and non-Posix) mapping between your
> monotonic time and broken-down calendar+time, a mapping which
> always requires you to have a perfect leap second table available.

Yes. I agree.

> And in fact, if you try to do (b), I believe that you are *not*
> really doing UTC, after all -- you are basically doing TAI
> (perhaps with a slightly different epoch), and misleadingly
> calling it UTC.  You are engendering just as much confusion as
> the Posix time_t definition does.  A monotonic count of seconds
> is simply not an appropriate representation for UTC.  The only
> proper representation(s) of UTC are those that separate the date
> from the time, so that they can cleanly, honestly, openly, and
> explicitly accommodate those pesky days of other than 86400
> seconds.

I think I agree with that as well.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646


From sla at ucolick.org  Mon Dec 16 15:07:12 2019
From: sla at ucolick.org (Steve Allen)
Date: Mon, 16 Dec 2019 07:07:12 -0800
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191216141021.GD490@davros.org>
References: <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
 <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
 <20191216141021.GD490@davros.org>
Message-ID: <20191216150712.GA8966@ucolick.org>

On Mon 2019-12-16T14:10:21+0000 Clive D.W. Feather hath writ:
> You take a Gregorian calendar (by default; in principle you could use
> Julian or something else) and use it to count *all* SI seconds, so that
> every day has exactly 86400 seconds in it. It works the same way as UT1,
> but without the unpredictable-length "seconds".

In 1968 between a pair of meetings the atomic clock and CCIR folks
ascertained that they could not use that scheme in broadcast time
signals, and that is when and why the notion of the leap second came
into being.

--
Steve Allen                    <sla at 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           https://www.ucolick.org/~sla/  Hgt +250 m


From clive at davros.org  Mon Dec 16 16:26:24 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 16:26:24 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
Message-ID: <20191216162624.GA97598@davros.org>

Guy Harris said:
> So are A-style representations defined for both UTC and TAI?  ITU-R Recommendation TF.460-6 says:
> 
> 	2 Leap-seconds
> 
> 	2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September.
> 
> 	2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex 3).
> 
> but where 1) the form HHh Mmm SSs for time stamps specified for UTC, 2) is that also specified for TAI?, 3) is it stated anywhere how days are indicated in this context (YYYY-MM-DD?  DD MMMMM YYYY?)

Hmm.

> What that Recommendation says is
> 
> 	B International atomic time (TAI)
> 
> 	The international reference scale of atomic time (TAI), based on the second (SI), as realized on the rotating geoid, is formed by the BIPM on the basis of clock data supplied by cooperating establishments. It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 (adopted by the CGPM 1971).
> 
> 	C Coordinated universal time (UTC)
> 
> 	UTC is the time-scale maintained by the BIPM, with assistance from the IERS, which forms the basis of a coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI but differs from it by an integer number of seconds.
> 
> 	The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leap-seconds) to ensure approximate agreement with UT1.
> 
> which, at most, says that, *for example*, TAI is in the form of days (presumably days that are always exactly 86400 seconds long)), hours. minutes, and seconds from "the origin 1 January 1958" (does that mean "midnight, 1 January 1958"?).

That says rather less than I expected. Equally, it doesn't say that much
about UTC either.

I would have thought "differs from it by an integer number of seconds" only
makes sense if they use the same representation when calcualting the
difference.

> If, in fact, "days" correspond to exactly-86400-second-long days,

I think they do.

> and "the origin 1 January 1958" is "midnight, 1 January 1958", TAI could also be represented as a scale of seconds since the origin 1 January 1958, with conversion between those two scales being straightforward (division and remainder to go from the second scale to the first, multiplication and addition to go from the first scale to the second, given that there are no leap seconds, month lengths, or leap years to worry about).

Okay, using a JD-style day count. But ...

> Can TAI also be represented as an absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day?  If so, are there any specified rules for that?  (Conversion to or from that scale from either of the scales mentioned in the previous paragraph is a little more work, as you'd have to worry about month lengths and leap years).

I think that was probably ignored as an issue, since "everyone knows" how
the calendar works. The ISO 8601 rules for date sequences work perfectly
well and there's no reason to re-state them.

> And in what ways could the UTC scale be represented?  The "differs from it by an integral number of seconds", with the difference varying over time, would presumably be a difference between the "absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day" representations of TAI or UTC, given that "It corresponds exactly in rate with TAI" means that, for the "days, hours, minutes and seconds from the origin 1 January 1958" definition of TAI,

Okay so far.

> every one of those seconds occurs in UTC as well,

But some of them with an xx:xx:60 label (and, in theory, some xx:xx:59
labels missing).

> so if you represent UTC as a count of days, hours, minutes, and seconds from some origin, or just as a count of seconds from that origin, the difference between the two scales, in seconds, is the difference between the origins, in seconds.

I've always read it as the difference being the difference in broken-down
time labels (xx:xx:05 v xx:xx:41, or whatever) and *not* a difference in
seconds since some epoch.

> Annex 3 of that recommendation, "Dating of events in the vicinity of a leap-second", shows events being dated "30 June, 23h 59m 60.6s UTC"; as it's an example, the year is omitted, so presumably the "30 June" would have a year number after it for a real event, i.e. an absolute Gregorian-style date.

More evidence that they viewed the calendar bit was "well-known".

> > Me, I would say that (1) and (4) are completely compatible --
> > they're two different representations for the same underlying
> > time scale.  You can perfectly interconvert between them using
> > the same algorithm Posix defines for time_t.
> > 
> > When it comes to UTC, however, (2) and (3) are most definitely
> > not compatible.  Personally, I believe that (2) is the *only*
> > way to represent UTC.  I believe -- Posix time_t most assuredly
> > notwithstanding -- that (3) is an abomination.
> 
> (2) and (3) are both problematic.
> 
> With (2), time stamps for events defined to occur at a specified sufficiently large number of seconds in the future cannot be predicted.  That includes all events with times specified by a (1)-style or (4)-style time stamp if those times go past what the IERS has specified.

Of course. This is the basic "leap seconds problem".

> With (3), some time stamps cannot be specified - including time stamps for events in the *past*, such as an event occurring on 30 June 2015 at 23h 59m 60s UTC.

And that's the Posix problem.

[...]

> So if we want to describe *any* timekeeping scheme that represents times in a format that is, or can trivially be converted to and from without loss of information, a count of seconds, including leap seconds, since some epoch, as "TAI", OK.  That does *not*, of course, mean that the epoch needs to be expressed as a TAI time stamp; "seconds, including leap seconds, since 1970-01-01 00:00:00 UTC" would then be a representation of TAI (given that we know what instant of time was labeled 1970-01-01 00:00:00 UTC - no knowledge of the future is needed there).

Okay; I don't dispute that either.

Bluetooth Mesh used a TAI 00:00:00 epoch to simplify the conversion between
seconds-since-epoch and hh:mm:ss in people's minds. I accept that the only
difference between that and a UTC 00:00:00 epoch is a constant offset equal
to TAI-UTC at the moment of the epoch.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646


From clive at davros.org  Mon Dec 16 16:27:50 2019
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 16 Dec 2019 16:27:50 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <20191216150712.GA8966@ucolick.org>
References: <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <1667.1576368244@jinx.noi.kre.to>
 <ed0dbb13-d7b1-3ede-44e3-c6cb7148abf7@googlemail.com>
 <C4182841-7D22-4350-ACE5-9935D5E753DE@alum.mit.edu>
 <20191216141021.GD490@davros.org>
 <20191216150712.GA8966@ucolick.org>
Message-ID: <20191216162750.GB97598@davros.org>

Steve Allen said:
> On Mon 2019-12-16T14:10:21+0000 Clive D.W. Feather hath writ:
> > You take a Gregorian calendar (by default; in principle you could use
> > Julian or something else) and use it to count *all* SI seconds, so that
> > every day has exactly 86400 seconds in it. It works the same way as UT1,
> > but without the unpredictable-length "seconds".
> 
> In 1968 between a pair of meetings the atomic clock and CCIR folks
> ascertained that they could not use that scheme in broadcast time
> signals,

*because* it drifts away from UT1, right? I'm not disputing that; I'm
simply saying that it works in the same way, just using real SI seconds
rather than sideral seconds.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646


From missmistie27 at gmail.com  Mon Dec 16 17:39:54 2019
From: missmistie27 at gmail.com (Misty HICKMAN)
Date: Mon, 16 Dec 2019 11:39:54 -0600
Subject: [tz] (no subject)
Message-ID: <CAPLvikk9jfVYa5jM1cXQvCaCFmk-KKccMNRvHy3kJhk_K8vz6A@mail.gmail.com>

 Yes .   MistY       18months now .    Very clear     you know. The
cAlEndAr Y ear ?       Remember the TeaCUp ..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191216/82808396/attachment.htm>

From Brian.Inglis at SystematicSw.ab.ca  Mon Dec 16 19:03:14 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Mon, 16 Dec 2019 12:03:14 -0700
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
Message-ID: <b026b59e-7c10-650a-00c3-d37aa4d3bfdb@SystematicSw.ab.ca>

On 2019-12-14 12:23, Guy Harris wrote:
> On Dec 14, 2019, at 8:00 AM, Steve Summit wrote:
>> Guy Harris wrote:
>>> On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather wrote:
>>>> Guy Harris said:

> ITU-R Recommendation TF.460-6 says:
> 
> 	2 Leap-seconds
> 
> 2.1 A positive or negative leap-second should be the last second of a UTC
> month, but first preference should be given to the end of December and June, and
> second preference to the end of March and September.
> 
> 2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the 
> first day of the following month. In the case of a negative leap-second, 23h
> 59m 58s will be followed one second later by 0h 0m 0s of the first day of
> the following month (see Annex 3).
> 
> but where 1) the form HHh Mmm SSs for time stamps specified for UTC, 2) is 
> that also specified for TAI?, 3) is it stated anywhere how days are indicated
> in this context (YYYY-MM-DD? DD MMMMM YYYY?)
> 
> What that Recommendation says is
> 
> B International atomic time (TAI)
> 
> The international reference scale of atomic time (TAI), based on the second 
> (SI), as realized on the rotating geoid, is formed by the BIPM on the basis
> of clock data supplied by cooperating establishments. It is in the form of a 
> continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 
> January 1958 (adopted by the CGPM 1971).
> 
> C Coordinated universal time (UTC)
> 
> UTC is the time-scale maintained by the BIPM, with assistance from the IERS, 
> which forms the basis of a coordinated dissemination of standard frequencies
> and time signals. It corresponds exactly in rate with TAI but differs from it
> by an integer number of seconds.
> 
> The UTC scale is adjusted by the insertion or deletion of seconds (positive 
> or negative leap-seconds) to ensure approximate agreement with UT1.
> 
> which, at most, says that, *for example*, TAI is in the form of days 
> (presumably days that are always exactly 86400 seconds long)), hours. 
> minutes, and seconds from "the origin 1 January 1958" (does that mean 
> "midnight, 1 January 1958"?).  If, in fact, "days" correspond to 
> exactly-86400-second-long days, and "the origin 1 January 1958" is
> "midnight, 1 January 1958", TAI could also be represented as a scale of
> seconds since the origin 1 January 1958, with conversion between those two
> scales being straightforward (division and remainder to go from the second
> scale to the first, multiplication and addition to go from the first scale to
> the second, given that there are no leap seconds, month lengths, or leap
> years to worry about).

Just to muddy things further, in an article in "Polar Motion: Historical and
Scientific Problems", ASP Conference Series, Vol. 208, also IAU Colloquium #178.
Edited by Steven Dick, Dennis McCarthy, and Brian Luzum. (San Francisco: ASP)
ISBN: 1-58381-039-0, 2000., "History of the Bureau International de l'Heure",
Guinot, B., p.181:

	http://articles.adsabs.harvard.edu/pdf/2000ASPC..208..175G#page=7

states in the third paragraph:

"By convention, all integrated atomic times, at BIH and elsewhere, were set so
that an event at 1958 January 1, 0h UT2, receive the same date in UT2 and atomic
time scales. However, the observatories used their own values of UT2: that
explains that longitude errors of a few 0.01s appear in the local independent
time scales, as they are presently realized."

Reading that page and the next, it is apparent that AT, AM, A3, TA, TAI
frequencies have been tweaked and steered to maintain consistency with earlier
timescales and standards as well as between organizations. See also:

	https://www.ucolick.org/~sla/leapsecs/taiepoch.html

and linked Bulletin Horaire scans, also:

	https://www.bipm.org/en/bipm-services/timescales/tai.html

"The long-term stability of TAI is assured by weighting the participating
clocks. The scale unit of TAI is kept as close as possible to the SI second by
using data from those national laboratories which maintain the best primary
caesium standards."

so all should bear in mind that TAI is a synthetic timescale calculated and
adjusted in arrears, so shares some of the same problems as leap seconds but
occurring at higher precisions.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


From michael.h.deckers at googlemail.com  Mon Dec 16 21:11:59 2019
From: michael.h.deckers at googlemail.com (Michael H Deckers)
Date: Mon, 16 Dec 2019 21:11:59 +0000
Subject: [tz] isdst bug Europe/Dublin (tzdb-2019c)
In-Reply-To: <b026b59e-7c10-650a-00c3-d37aa4d3bfdb@SystematicSw.ab.ca>
References: <20191207172105.GA18617@cedar>
 <9d8b65d8-4183-f5c1-a615-ea5db0e724fb@cs.ucla.edu>
 <4B90567A-8776-4C4C-95CD-3F3AC9745B03@alum.mit.edu>
 <20191211192327.GA18736@cedar> <20191213221336.GE24121@davros.org>
 <73D966D7-239C-47E6-8D63-C8E135BA1322@alum.mit.edu>
 <20191214092322.GB30165@davros.org>
 <A0F75A4B-DDC2-46BF-B9CE-EA9219CD3590@alum.mit.edu>
 <2019Dec14.1100.scs.0003@quinine2.home>
 <167207DC-0906-4117-B051-C01D72429869@alum.mit.edu>
 <b026b59e-7c10-650a-00c3-d37aa4d3bfdb@SystematicSw.ab.ca>
Message-ID: <3bd225aa-f496-0609-8e39-f1cafb1ab2d5@googlemail.com>


 ?? On 2019-12-16 19:03, Brian Inglis wrote:


> Just to muddy things further, in an article in "Polar Motion: Historical and
> Scientific Problems", ASP Conference Series, Vol. 208, also IAU Colloquium #178.
> Edited by Steven Dick, Dennis McCarthy, and Brian Luzum. (San Francisco: ASP)
> ISBN: 1-58381-039-0, 2000., "History of the Bureau International de l'Heure",
> Guinot, B., p.181:
>
> 	http://articles.adsabs.harvard.edu/pdf/2000ASPC..208..175G#page=7


 ?? Thanks for the reference!


> ...so all should bear in mind that TAI is a synthetic timescale calculated and
> adjusted in arrears, so shares some of the same problems as leap seconds but
> occurring at higher precisions.


 ?? "adjusted in arrears":
 ????? The definitive values of TAI are fixed about a month after the fact
 ????? (fast in astronomical terms!) by Circular T. A more uniform time 
scale
 ????? can be obtained when more than a month's future data are used; such
 ????? evaluations are done by the BIPM and published yearly as estimates
 ????? TT(BIPM xx) of TT.

 ?? "same problems as leap seconds":
 ????? I do not think so. That is, no astronomical observations (eg,
 ????? satellite orbits, pulsar timings) can currently reach or exceed
 ????? the accuracy of the determination of TT with earth-bound clocks,
 ????? and the upcoming use of optical clocks will lead to a significant
 ????? increase in accuracy. Nor is there any sign of a systematic
 ????? difference in rate between TAI and TT -- it would be "new physics",
 ????? I guess.

 ??? Michael Deckers.



From wyuenho at gmail.com  Thu Dec 19 11:26:40 2019
From: wyuenho at gmail.com (Jimmy Yuen Ho Wong)
Date: Thu, 19 Dec 2019 11:26:40 +0000
Subject: [tz] [PATCH] * asia: Correct Hong Kong section name.
Message-ID: <20191219112639.927-1-wyuenho@gmail.com>

There are no records of Hong Kong being referred to as Xianggang, in the past or
currently. The Pinyin romanization scheme of the Mandarin pronunciation of ??
is not officially recognized or even mentioned in official documents.

https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html

https://www.elegislation.gov.hk/hk/cap5
---
 asia | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/asia b/asia
index cca004f..4f19d14 100644
--- a/asia
+++ b/asia
@@ -572,7 +572,7 @@ Zone	Asia/Urumqi	5:50:20	-	LMT	1928
 			6:00	-	+06
 
 
-# Hong Kong (Xianggang)
+# Hong Kong
 
 # Milne gives 7:36:41.7; round this.
 
-- 
2.24.0



From eggert at cs.ucla.edu  Thu Dec 19 22:48:46 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Thu, 19 Dec 2019 14:48:46 -0800
Subject: [tz] [PATCH] * asia: Correct Hong Kong section name.
In-Reply-To: <20191219112639.927-1-wyuenho@gmail.com>
References: <20191219112639.927-1-wyuenho@gmail.com>
Message-ID: <176436bd-675d-f90d-4ef7-226bc3cd2d28@cs.ucla.edu>

Thanks, I installed that.


From wyuenho at gmail.com  Wed Dec 18 19:34:39 2019
From: wyuenho at gmail.com (Jimmy Yuen Ho Wong)
Date: Wed, 18 Dec 2019 19:34:39 +0000
Subject: [tz] [PATCH] * asia: Correct Hong Kong section name.
Message-ID: <20191218193438.99112-1-wyuenho@gmail.com>

There are no records of Hong Kong being referred to as Xianggang, in the past or
currently. The Pinyin romanization scheme of the Mandarin pronunciation of ??
is not officially recognized or even mentioned in official documents.

https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html

https://www.elegislation.gov.hk/hk/cap5
---
 asia | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/asia b/asia
index cca004f..4f19d14 100644
--- a/asia
+++ b/asia
@@ -572,7 +572,7 @@ Zone	Asia/Urumqi	5:50:20	-	LMT	1928
 			6:00	-	+06
 
 
-# Hong Kong (Xianggang)
+# Hong Kong
 
 # Milne gives 7:36:41.7; round this.
 
-- 
2.24.0



From arthurdavidolson at gmail.com  Tue Dec 24 21:14:26 2019
From: arthurdavidolson at gmail.com (Arthur David Olson)
Date: Tue, 24 Dec 2019 16:14:26 -0500
Subject: [tz] Timekeeping in the news
Message-ID: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>

"Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."

https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html

    @dashdashado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/a8d0e2ca/attachment.htm>

From marshall.eubanks at gmail.com  Wed Dec 25 00:41:48 2019
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Tue, 24 Dec 2019 19:41:48 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
Message-ID: <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>

It was a time transfer error - the mission elapsed time clock was off
by 11 hours because it took the wrong time from the Atlas at
separation. They were very lucky not to lose the spacecraft.

https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/

Regards
Marshall Eubanks

On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
<arthurdavidolson at gmail.com> wrote:
>
> "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
>
> https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
>
>     @dashdashado


From alan.mintz at gmail.com  Wed Dec 25 01:46:46 2019
From: alan.mintz at gmail.com (Alan Mintz)
Date: Tue, 24 Dec 2019 17:46:46 -0800
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
Message-ID: <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>

Here's the NYT article that mentions the 11 hours:
https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an
interesting (though "armchair") analysis, noting that the mission countdown
started at T-11 hours:
https://forum.nasaspaceflight.com/index.php?topic=43958.860 .


On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <marshall.eubanks at gmail.com>
wrote:

> It was a time transfer error - the mission elapsed time clock was off
> by 11 hours because it took the wrong time from the Atlas at
> separation. They were very lucky not to lose the spacecraft.
>
>
> https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
>
> Regards
> Marshall Eubanks
>
> On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
> <arthurdavidolson at gmail.com> wrote:
> >
> > "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
> >
> > https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
> >
> >     @dashdashado
>


-- 
Alan Mintz <Alan.Mintz at gMail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/c9c63892/attachment.htm>

From alan.mintz at gmail.com  Wed Dec 25 01:48:52 2019
From: alan.mintz at gmail.com (Alan Mintz)
Date: Tue, 24 Dec 2019 17:48:52 -0800
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
Message-ID: <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>

Oops. The correct NYT link for the 11 hours:
https://www.nytimes.com/2019/12/22/science/boeing-starliner-landing.html .

On Tue, Dec 24, 2019 at 5:46 PM Alan Mintz <alan.mintz at gmail.com> wrote:

> Here's the NYT article that mentions the 11 hours:
> https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an
> interesting (though "armchair") analysis, noting that the mission countdown
> started at T-11 hours:
> https://forum.nasaspaceflight.com/index.php?topic=43958.860 .
>
>
> On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <
> marshall.eubanks at gmail.com> wrote:
>
>> It was a time transfer error - the mission elapsed time clock was off
>> by 11 hours because it took the wrong time from the Atlas at
>> separation. They were very lucky not to lose the spacecraft.
>>
>>
>> https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
>>
>> Regards
>> Marshall Eubanks
>>
>> On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
>> <arthurdavidolson at gmail.com> wrote:
>> >
>> > "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
>> >
>> > https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
>> >
>> >     @dashdashado
>>
>
>
> --
> Alan Mintz <Alan.Mintz at gMail.com>
>


-- 
Alan Mintz <Alan.Mintz at gMail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/bab5ce49/attachment.htm>

From howard.hinnant at gmail.com  Wed Dec 25 03:02:57 2019
From: howard.hinnant at gmail.com (Howard Hinnant)
Date: Tue, 24 Dec 2019 22:02:57 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
Message-ID: <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>

11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).  It would be great to know the facts...

Howard

On Dec 24, 2019, at 8:48 PM, Alan Mintz <alan.mintz at gmail.com> wrote:
> 
> Oops. The correct NYT link for the 11 hours: https://www.nytimes.com/2019/12/22/science/boeing-starliner-landing.html .
> 
> On Tue, Dec 24, 2019 at 5:46 PM Alan Mintz <alan.mintz at gmail.com> wrote:
> Here's the NYT article that mentions the 11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an interesting (though "armchair") analysis, noting that the mission countdown started at T-11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 .
> 
> 
> On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> It was a time transfer error - the mission elapsed time clock was off
> by 11 hours because it took the wrong time from the Atlas at
> separation. They were very lucky not to lose the spacecraft.
> 
> https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
> 
> Regards
> Marshall Eubanks
> 
> On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
> <arthurdavidolson at gmail.com> wrote:
> >
> > "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
> >
> > https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
> >
> >     @dashdashado
> 
> 
> --
> Alan Mintz <Alan.Mintz at gMail.com>
> 
> 
> --
> Alan Mintz <Alan.Mintz at gMail.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/4a1d7a55/attachment.sig>

From marshall.eubanks at gmail.com  Wed Dec 25 03:11:23 2019
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Tue, 24 Dec 2019 22:11:23 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
Message-ID: <CAJNg7VJmkwuPiTqPrxkBn-nf_Cf3Q-KyU3J+FbM7DxgyFibpDQ@mail.gmail.com>

On Tue, Dec 24, 2019 at 10:03 PM Howard Hinnant
<howard.hinnant at gmail.com> wrote:
>
> 11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).

No, India is 5 hours and 30 minutes ahead of UTC and 10 hr 30 min
ahead of EST, and that half an hour does indeed matter.

Regards
Marshall

> It would be great to know the facts...
>
> Howard
>
> On Dec 24, 2019, at 8:48 PM, Alan Mintz <alan.mintz at gmail.com> wrote:
> >
> > Oops. The correct NYT link for the 11 hours: https://www.nytimes.com/2019/12/22/science/boeing-starliner-landing.html .
> >
> > On Tue, Dec 24, 2019 at 5:46 PM Alan Mintz <alan.mintz at gmail.com> wrote:
> > Here's the NYT article that mentions the 11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an interesting (though "armchair") analysis, noting that the mission countdown started at T-11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 .
> >
> >
> > On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> > It was a time transfer error - the mission elapsed time clock was off
> > by 11 hours because it took the wrong time from the Atlas at
> > separation. They were very lucky not to lose the spacecraft.
> >
> > https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
> >
> > Regards
> > Marshall Eubanks
> >
> > On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
> > <arthurdavidolson at gmail.com> wrote:
> > >
> > > "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
> > >
> > > https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
> > >
> > >     @dashdashado
> >
> >
> > --
> > Alan Mintz <Alan.Mintz at gMail.com>
> >
> >
> > --
> > Alan Mintz <Alan.Mintz at gMail.com>
>


From howard.hinnant at gmail.com  Wed Dec 25 03:26:37 2019
From: howard.hinnant at gmail.com (Howard Hinnant)
Date: Tue, 24 Dec 2019 22:26:37 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAJNg7VJmkwuPiTqPrxkBn-nf_Cf3Q-KyU3J+FbM7DxgyFibpDQ@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
 <CAJNg7VJmkwuPiTqPrxkBn-nf_Cf3Q-KyU3J+FbM7DxgyFibpDQ@mail.gmail.com>
Message-ID: <A1BA9855-9005-4F5C-A4EC-369F6B3C4085@gmail.com>

Ah, my mistake.  I missed the 30min, thanks.

Howard

On Dec 24, 2019, at 10:11 PM, Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
> 
> On Tue, Dec 24, 2019 at 10:03 PM Howard Hinnant
> <howard.hinnant at gmail.com> wrote:
>> 
>> 11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).
> 
> No, India is 5 hours and 30 minutes ahead of UTC and 10 hr 30 min
> ahead of EST, and that half an hour does indeed matter.
> 
> Regards
> Marshall
> 
>> It would be great to know the facts...
>> 
>> Howard
>> 
>> On Dec 24, 2019, at 8:48 PM, Alan Mintz <alan.mintz at gmail.com> wrote:
>>> 
>>> Oops. The correct NYT link for the 11 hours: https://www.nytimes.com/2019/12/22/science/boeing-starliner-landing.html .
>>> 
>>> On Tue, Dec 24, 2019 at 5:46 PM Alan Mintz <alan.mintz at gmail.com> wrote:
>>> Here's the NYT article that mentions the 11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 and an interesting (though "armchair") analysis, noting that the mission countdown started at T-11 hours: https://forum.nasaspaceflight.com/index.php?topic=43958.860 .
>>> 
>>> 
>>> On Tue, Dec 24, 2019 at 4:42 PM Marshall Eubanks <marshall.eubanks at gmail.com> wrote:
>>> It was a time transfer error - the mission elapsed time clock was off
>>> by 11 hours because it took the wrong time from the Atlas at
>>> separation. They were very lucky not to lose the spacecraft.
>>> 
>>> https://arstechnica.com/science/2019/12/something-went-wrong-with-the-starliner-spacecrafts-first-flight/
>>> 
>>> Regards
>>> Marshall Eubanks
>>> 
>>> On Tue, Dec 24, 2019 at 4:15 PM Arthur David Olson
>>> <arthurdavidolson at gmail.com> wrote:
>>>> 
>>>> "Boeing Starliner Ends Up In Wrong Orbit After Clock Problem."
>>>> 
>>>> https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html
>>>> 
>>>>    @dashdashado
>>> 
>>> 
>>> --
>>> Alan Mintz <Alan.Mintz at gMail.com>
>>> 
>>> 
>>> --
>>> Alan Mintz <Alan.Mintz at gMail.com>
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/040147ac/attachment.sig>

From tim at timtimeonline.com  Wed Dec 25 03:28:24 2019
From: tim at timtimeonline.com (Tim Parenti)
Date: Tue, 24 Dec 2019 22:28:24 -0500
Subject: [tz] Timekeeping in the news
In-Reply-To: <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
Message-ID: <CAFpi07w0dxvbC_DknxvtNy7MF4qt7J603n6J80g13FBgG0aFog@mail.gmail.com>

On Tue, 24 Dec 2019 at 22:03, Howard Hinnant <howard.hinnant at gmail.com>
wrote:

> 11h...  Sure smells like a time zone issue.  Such as not taking time zones
> into account, or taking them into account incorrectly.  Fwiw, there?s an
> 11h difference between Cape Canaveral (launch site) and India (popular
> location for outsourced programming).


I have seen speculation on Twitter (unsubstantiated, of course) that it is
related to the difference between Cape Canaveral (currently UTC-5) and
the Baikonur Cosmodrome in Kazakhstan (UTC+6).  But anything of that sort
would of course raise the question of why *any* local time is being used
rather than UTC.

It would be great to know the facts...


Indeed.  I've only seen the phrase "11 hours" in reports, but of course, if
that's being used as an approximate figure rather than an exact one, there
could be any number of other possible causes.

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20191224/d7584b32/attachment.htm>

From PaulGBoulder at AIM.com  Wed Dec 25 04:37:01 2019
From: PaulGBoulder at AIM.com (Paul Gilmartin)
Date: Tue, 24 Dec 2019 21:37:01 -0700
Subject: [tz] Timekeeping in the news
In-Reply-To: <CAFpi07w0dxvbC_DknxvtNy7MF4qt7J603n6J80g13FBgG0aFog@mail.gmail.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
 <CAFpi07w0dxvbC_DknxvtNy7MF4qt7J603n6J80g13FBgG0aFog@mail.gmail.com>
Message-ID: <ED91395F-F1A8-4D50-BA97-FFED975AB159@AIM.com>

On 2019-12-24, at 20:28:24, Tim Parenti wrote:
> 
> On Tue, 24 Dec 2019 at 22:03, Howard Hinnant <howard.hinnant at gmail.com> wrote:
> 11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).
> 
> I have seen speculation on Twitter (unsubstantiated, of course) that it is related to the difference between Cape Canaveral (currently UTC-5) and the Baikonur Cosmodrome in Kazakhstan (UTC+6).  But anything of that sort would of course raise the question of why any local time is being used rather than UTC.
>  
One NASA convention is "Mission Elapsed Time":
    https://en.wikipedia.org/wiki/Mission_Elapsed_Time

... but they still have to get it right.

> It would be great to know the facts...
> 
> Indeed.  I've only seen the phrase "11 hours" in reports, but of course, if that's being used as an approximate figure rather than an exact one, there could be any number of other possible causes.
>  
In 1985 in Colorado, a fatal train wreck resulted from a scheduling error:
    https://www.ntsb.gov/investigations/AccidentReports/Pages/RAR8602.aspx

Speculation at the time, not confirmed in the NTSB report, was that one
train on Friday picked handwritten orders for Saturday.

-- gil



From Brian.Inglis at SystematicSw.ab.ca  Fri Dec 27 16:46:55 2019
From: Brian.Inglis at SystematicSw.ab.ca (Brian Inglis)
Date: Fri, 27 Dec 2019 09:46:55 -0700
Subject: [tz] Timekeeping in the news
In-Reply-To: <ED91395F-F1A8-4D50-BA97-FFED975AB159@AIM.com>
References: <CAJvZEY=f3uS4STR-LOOG4grEN4gFCOtDTCqydO2tiuU3ToVhjw@mail.gmail.com>
 <CAJNg7VJ2zPxMNv12H7X7ZU65hRGExYN7R3SmLey4cZFeCjcejw@mail.gmail.com>
 <CAMLM5-VD2=kv=bKLP3Yf8xFWozEDOh3Cd2Eu2SzGtj_2f=_7Aw@mail.gmail.com>
 <CAMLM5-Wb+mLH9hSpWxNb_r=AKR5NQFpj1DYUmzhe48+SqfT2Tg@mail.gmail.com>
 <7B8A0815-1B90-4C35-80C8-CFFBE86AD305@gmail.com>
 <CAFpi07w0dxvbC_DknxvtNy7MF4qt7J603n6J80g13FBgG0aFog@mail.gmail.com>
 <ED91395F-F1A8-4D50-BA97-FFED975AB159@AIM.com>
Message-ID: <1a68d51d-7298-c4a8-5584-794876d2aafe@SystematicSw.ab.ca>

On 2019-12-24 21:37, Paul Gilmartin via tz wrote:
> On 2019-12-24, at 20:28:24, Tim Parenti wrote:
>>
>> On Tue, 24 Dec 2019 at 22:03, Howard Hinnant <howard.hinnant at gmail.com> wrote:
>> 11h...  Sure smells like a time zone issue.  Such as not taking time zones into account, or taking them into account incorrectly.  Fwiw, there?s an 11h difference between Cape Canaveral (launch site) and India (popular location for outsourced programming).
>>
>> I have seen speculation on Twitter (unsubstantiated, of course) that it is related to the difference between Cape Canaveral (currently UTC-5) and the Baikonur Cosmodrome in Kazakhstan (UTC+6).  But anything of that sort would of course raise the question of why any local time is being used rather than UTC.
>>  
> One NASA convention is "Mission Elapsed Time":
>     https://en.wikipedia.org/wiki/Mission_Elapsed_Time
> 
> ... but they still have to get it right.
> 
>> It would be great to know the facts...

...article has the added link:

https://www.nasaspaceflight.com/2019/12/oft-starliner-landing-white-sands/

linking to:

https://www.nasaspaceflight.com/2019/12/boeing-ula-momentous-starliner-uncrewed-test-flight/

https://www.nasaspaceflight.com/2019/12/starliner-mission-shortening-failure-successful-launch/

Some suggestion that powered up time was used and Centaur MET was *NOT* used!
If so that would raise the suspicion that perhaps a test configuration may not
have been reconfigured for flight.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


From lester at lsces.uk  Tue Dec 31 07:20:39 2019
From: lester at lsces.uk (Lester Caine)
Date: Tue, 31 Dec 2019 07:20:39 +0000
Subject: [tz] Fake UK news
Message-ID: <116b07e3-f60a-b28b-9d06-9f74a166e778@lsces.uk>

Or rather another proposal for changes to time zones that did not happen 
- SDST

https://www.bbc.co.uk/news/uk-50950961

-- 
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk


From PaulGBoulder at AIM.com  Tue Dec 31 21:05:03 2019
From: PaulGBoulder at AIM.com (Paul Gilmartin)
Date: Tue, 31 Dec 2019 14:05:03 -0700
Subject: [tz] Hour 26?  (was: Chaning time zone for Unix based tasks)
References: <2EDF80BB-F614-456E-AEF2-1E1C22A6544A.ref@AIM.com>
Message-ID: <2EDF80BB-F614-456E-AEF2-1E1C22A6544A@AIM.com>

(cross-posting to tz and IBM-MAIN)
Hi, TZData,

On a Linux system, I see:
1043 $ uname -a
Linux Bunsen5-PG 4.9.0-11-686-pae #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) i686 GNU/Linux
1044 $ cat /usr/share/zoneinfo/Asia/Tel_Aviv   | tail -1
IST-2IDT,M3.4.4/26,M10.5.0
1045 $ 

... This would seem to be Month 3, Week 4, Day 4, hour 26.
26?  Is that supposed to be 02:00 the next day?

But POSIX says:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08
... The hour shall be between zero and 24, and the minutes (and seconds)
-if present-between zero and 59. The result of using values outside 
of this range is unspecified.

z/OS (which supports only POSIX format) seems to ignore that TZ
(as allowed by "unspecified") and use UTC0:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/bpxa50065.htm
(It doesn't specify.)

Ouch!
-- gil



From eggert at cs.ucla.edu  Tue Dec 31 23:46:00 2019
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Tue, 31 Dec 2019 15:46:00 -0800
Subject: [tz] Hour 26? (was: Chaning time zone for Unix based tasks)
In-Reply-To: <2EDF80BB-F614-456E-AEF2-1E1C22A6544A@AIM.com>
References: <2EDF80BB-F614-456E-AEF2-1E1C22A6544A.ref@AIM.com>
 <2EDF80BB-F614-456E-AEF2-1E1C22A6544A@AIM.com>
Message-ID: <34476839-faea-87e8-1933-67d1908787b9@cs.ucla.edu>

On 12/31/19 1:05 PM, Paul Gilmartin via tz wrote:

> 1044 $ cat /usr/share/zoneinfo/Asia/Tel_Aviv   | tail -1
> IST-2IDT,M3.4.4/26,M10.5.0
> 1045 $ 
> 
> ... This would seem to be Month 3, Week 4, Day 4, hour 26.
> 26?  Is that supposed to be 02:00 the next day?

Yes.

> POSIX says:

That's old news. Please see Internet RFC 8536 section 3.3.1 and
<http://austingroupbugs.net/view.php?id=1252>.