<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Sleep experts say Senate has it wrong:
Standard time, not daylight saving, should be permanent<br>
<a class="moz-txt-link-freetext" href="https://www.washingtonpost.com/wellness/2022/03/16/daylight-saving-bill-health-effects/">https://www.washingtonpost.com/wellness/2022/03/16/daylight-saving-bill-health-effects/</a><br>
<br>
-Brooks<br>
<br>
On 2022-03-16 9:53 AM, Brooks Harris via tz wrote:<br>
</div>
<blockquote cite="mid:6231EBE2.1010309@edlmax.com" type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Perhaps lobby the House of
Representatives to change the Bill to simply stop DST:<br>
<br>
A) Its a more natural reflection of daylight and seasons. Its
more in keeping with the age old tradition of keeping time by
the Sun in the sky. Its better for the population's sleep
patterns and so better for safety, health and productivity.<br>
<br>
B) Its a simple matter for tzdb to accommodate that rule and for
client systems to reflect it. There would be little or no
technical disruption of civil time.<br>
<br>
I want DST to go away, but I see "permanent DST" as an unnatural
distortion and technically disruptive. Perhaps if lawmakers were
made more aware if this there might be reconsideration of the
terms of the Bill.<br>
<br>
Thanks, <br>
-Brooks<br>
<br>
<br>
On 2022-03-16 12:45 AM, Chris Walton via tz wrote:<br>
</div>
<blockquote
cite="mid:CAG55VO6gi_jqBPzLOZZJEDLz13Dx2od-Ok3v+gOYr8XdnCN5HA@mail.gmail.com"
type="cite">
<div dir="ltr">Regardless of what the legislation does or does
not say, this database needs to quickly adopt a strategy to
deal with changes that may be necessary for all North American
Time zones.
<div>The supporters and maintainers of this time zone database
can take an active role in helping to define and endorse a
common standard, or they can sit back and watch the
politicians and the general public fumble the job. It would
be helpful if there was some collaboration between Microsoft
and the supporters/maintainers of this database.</div>
<div><br>
</div>
<div>I think it is likely that if the US government approves
the Sunshine Protection Act, that most Canadian provinces
and territories will follow with similar legislation.</div>
<div>- British Columbia and Ontario already have the necessary
legislation in place.<br>
- Saskatchewan has not changed its clocks in many years.<br>
- Yukon stopped changing its clocks in 2020.<br>
- Alberta recently voted to keep the biannual change, it
could be the lone holdout!<br>
I admit I have not been following the other Canadian
territories and provinces closely.</div>
<div>Also, I have no clue what Mexico, Saint Pierre &
Miquelon, or any of the small island nations will decide to
do.</div>
<div>
<div><br>
</div>
<div>For this database I can envision four options moving
forward:</div>
<div><br>
<b>Option #1</b>: ditch the three letter time zone strings
and use only numerical offsets from UTC.<br>
This is a complete cop out that says "Let's abandon our
end users and let somebody else deal with the issue". It
is my least favorite option.</div>
<div> e.g. Los Angeles, Phoenix, and Vancouver:<br>
Thu Feb 1 00:00:00 <b>-07</b> 2024 (UTC-07)<br>
Thu Aug 1 00:00:00 <b>-07</b> 2024 (UTC-07)<br>
e.g. New York and Toronto:<br>
Thu Feb 1 00:00:00 <b>-04</b> 2024 (UTC-04)<br>
Thu Aug 1 00:00:00 <b>-04</b> 2024 (UTC-04)<br>
<br>
<br>
<b>Option #2</b>: allow permanent daylight saving<br>
This could be implemented without too many complications,
but it goes against the philosophy that daylight saving is
an alternate time offset that is only used for part of the
year.</div>
<div>This is not my favorite option even though it is
probably the least disruptive. I do not think it will
make any sense 20 years from now.<br>
e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse
would be on permanent <b>Pacific Daylight Time</b><br>
Thu Feb 1 00:00:00 <b>PDT</b> 2024 (UTC-07)<br>
Thu Aug 1 00:00:00 <b>PDT</b> 2024 (UTC-07)<br>
e.g. New York and Toronto would be on permanent <b>Eastern
Daylight Time</b>:<br>
Thu Feb 1 00:00:00 <b>EDT </b>2024 (UTC-04)<br>
Thu Aug 1 00:00:00 <b>EDT</b> 2024 (UTC-04)<br>
<br>
<br>
<b>Option #3</b>: move most North American entries in the
TZ database one zone to the east:<br>
I know we have done this in the past for places such as
America/Whitehorse, but I expect if we did it for all of
Canada and the US it would not align with the public's
perception of reality. Also, it provides no clear path to
deal with any places that are currently using <b>Atlantic
Daylight Time (UTC-03)</b>.</div>
<div> e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse
would be on permanent <b>Mountain Standard Time</b><br>
Thu Feb 1 00:00:00 <b>MST</b> 2024 (UTC-07)<br>
Thu Aug 1 00:00:00 <b>MST</b> 2024 (UTC-07)<br>
e.g. New York and Toronto would be on permanent <b>Atlantic
Standard Time</b>:<br>
Thu Feb 1 00:00:00 <b>AST</b> 2024 (UTC-04)<br>
Thu Aug 1 00:00:00 <b>AST</b> 2024 (UTC-04)<br>
<br>
<br>
<b>Option #4</b>: redefine AKST, PST, MST, CST, EST, AST,
and NST to all be one hour closer to UTC time.<br>
This is currently my preferred option even though it may
break some software and it is guaranteed to conflict with
the Canadian Interpretation Act.<br>
Alaska Standard Time (AKST) is redefined to UTC-08.<br>
Pacific Standard Time (PST) is redefined to UTC-07.<br>
Mountain Standard Time (MST) is redefined to UTC-06.<br>
Central Standard Time (CST) is redefined to UTC-05.<br>
Eastern Standard Time (EST) is redefined to UTC-04.<br>
Atlantic Standard Time (AST) is redefined to UTC-03.<br>
Newfoundland Standard Time (NST) is redefined to
UTC-02:30 (assuming Newfoundland abandons the biannual
time change)<br>
e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse
would be on <b>Pacific Standard Time</b> year-round:<br>
Thu Feb 1 00:00:00 <b>PST</b> 2024 (UTC-07)<br>
Thu Aug 1 00:00:00 <b>PST</b> 2024 (UTC-07)<br>
e.g. New York and Toronto would be on <b>Eastern
Standard Time</b> year-round:<br>
Thu Feb 1 00:00:00 <b>EST</b> 2024 (UTC-04)<br>
Thu Aug 1 00:00:00 <b>EST</b> 2024 (UTC-04)<br>
e.g. Alberta would have to adopt new time zone names: <b>Pacific
Standard Time</b> in winter, and <b>Pacific Daylight
Time</b> in summer. (Alberta recently voted to keep the
biannual clock change).<br>
Thu Feb 1 00:00:00 <b>PST</b> 2024 (UTC-07)<br>
Thu Aug 1 00:00:00 <b>PDT</b> 2024 (UTC-06)<br>
e.g. Saskatchewan would have to start referring to its
time zone name as <b>Mountain Standard Time</b> instead
of <b>Central Standard Time</b>. (Saskatchewan has used <b>UTC-06</b>
year-round for many years)<br>
Thu Feb 1 00:00:00 <b>MST</b> 2024 (UTC-06)<br>
Thu Aug 1 00:00:00 <b>MST</b> 2024 (UTC-06)<br>
e.g. Puerto Rico would have to start referring to its
time zone as <b>Eastern Standard Time</b> instead of <b>Atlantic
Standard Time</b>.<br>
Thu Feb 1 00:00:00 <b>EST</b> 2024 (UTC-04)<br>
Thu Aug 1 00:00:00 <b>EST</b> 2024 (UTC-04)<br>
e.g. If Atlantic Canada and Bermuda were to continue
changing the clocks twice a year, they would be on <b>Eastern
Standard Time</b> in winter and <b>Eastern Daylight
Time</b> in summer.<br>
Thu Feb 1 00:00:00 <b>EST</b> 2024 (UTC-04)<br>
Thu Aug 1 00:00:00 <b>EDT</b> 2024 (UTC-03)<br>
e.g. If, Atlantic Canada and Bermuda were to abandon the
time change, then they would both end up on <b>Atlantic
Standard Time</b> year-round.<br>
Thu Feb 1 00:00:00 <b>AST</b> 2024 (UTC-03)<br>
Thu Aug 1 00:00:00 <b>AST</b> 2024 (UTC-03)<br>
<br>
Did I miss anything?</div>
</div>
<div>-chris</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>