<div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>I was asked, possibly sarcastically, to clarify what I meant by, "midnight Eastern time." I will attempt to clarify that within the bounds of current scientific knowledge and technical capabilities. Relevant links to international or national standards and research papers are provided.</div><div><br></div><div>Unless stated otherwise, any dates or times referred to in NEMS announcements are <a href="https://www.bipm.org/en/bipm/tai/">Universal Correlated Time (UTC)</a>, based on the <a href="https://www.nist.gov/pml/time-and-frequency-division/services/internet-time-service-its">National Institute of Standards and Technology (NIST) Internet Time Standard</a>, with the <a href="https://nationalmap.gov/small_scale/mld/timeznp.html">local timezone adjustment</a> valid at <a href="http://commerce.maryland.gov/Documents/BusinessResource/NCWCP-NOAA-Center-Weather-Climate-Prediction.pdf">NCWCP</a> at that time. <a href="https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat">When relevant</a>, <a href="https://www.nist.gov/pml/time-and-frequency-division/leap-seconds-faqs">leap</a> <a href="https://physics.nist.gov/cuu/Units/second.html">seconds</a> will be <a href="https://www.gps.gov/news/2015/05/leap-second/2015-best-practices-for-leap-second.pdf">specified</a>. On both dates in question, the adjustment is -5 <a href="https://www.bipm.org/en/publications/si-brochure/table6.html">hours</a> relative to UTC. The approximate internet time can be viewed at <a href="https://time.gov">time.gov</a>, but that time will be imprecise and inaccurate due to the <a href="https://ieeexplore.ieee.org/document/802014">inherent delays in TCP/IP</a>, magnified by issues with <a href="https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/page-load-timing-process">webpage load times</a>. Some better approximations are:</div><div><br></div><div>1. The <a href="https://www.usno.navy.mil/USNO/time/gps/usno-gps-time-transfer">GPS time</a>. However, this suffers from <a href="https://eclipse2017.nasa.gov/testing-general-relativity">general relativistic</a> effects which cause a <a href="https://link.springer.com/article/10.12942/lrr-2003-1">significant deviation in the time, that is partially corrected</a>.</div><div><br></div><div>2. <a href="https://www.nist.gov/pml/time-and-frequency-division/radio-stations/wwv">NIST Broadcast Time</a>, available via <a href="https://science.nasa.gov/ems/05_radiowaves">radio</a> at 2.5, 5, 10, 15, and 20 MHz. As noted on <a href="https://www.nist.gov/pml/time-and-frequency-division/radio-stations/wwv">their website</a>, there are a variety of effects that must be considered for sub-second precision.</div><div><br></div><div>3. The <a href="http://www.ntp.org/">Network Time Protocol</a>, used to set time on typical computers. This suffers from the same TCP/IP delays as <a href="http://time.gov">time.gov</a>, but not webpage load times.</div><div><br></div><div>Other possible time sources, and different definitions of time other than UTC, are described throughout the <a href="https://www.bipm.org/en/bipm-services/timescales/">BIPM website</a>. As discussed on their website, as of this writing, high-precision definitions of time deviate by at most 37 seconds.</div><div><br></div><div>Lastly, as noted by the <a href="https://www.nist.gov/time-and-frequency-division/times-day-frequently-asked-questions-faq#noon">NIST Time of Day FAQ</a>, "12 a.m. and 12 p.m. are ambiguous and should not be used." Using "midnight at the end of" or "midnight at the beginning of" a particular <a href="https://www.bipm.org/en/publications/si-brochure/table6.html">day</a> removes ambiguity by referring to the moment at which the day begins and ends in UTC. However, this can lead to confusion because of the <a href="https://en.wikipedia.org/wiki/Day">multiple concepts known as "day."</a></div><div><br></div><div>As a good "rule of thumb," you should assume a +/- 5 minute window around times in NEMS announcements to allow different definitions of the time, general relativistic effects, uncalibrated clocks, technological limitations (like TCP/IP delays), differences in the understanding of the word "day," and other issues in time specification.</div><div><br></div><div>Sincerely,</div><div>Sam Trahan</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 15 Nov 2018 at 08:01, Samuel Trahan - NOAA Affiliate <<a href="mailto:samuel.trahan@noaa.gov">samuel.trahan@noaa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>After today's NEMS and FMS commits, we're instituting a temporary freeze of the NEMS master and GFS-FMS. Only emergency commits will be allowed. This is necessary to allow some urgent FV3 commits to come in to its master. </div><div><br></div><div>To be specific, these are frozen:</div><div><br></div><div>branch "master" of ssh://<a href="http://vlab.ncep.noaa.gov:29418/NEMS" target="_blank">vlab.ncep.noaa.gov:29418/NEMS</a><br></div><div>branch "GFS-FMS" of <a href="https://github.com/NOAA-EMC/FMS" target="_blank">https://github.com/NOAA-EMC/FMS</a></div><div><br></div><div>from midnight at the beginning of Friday, November 16, 2018 (Eastern time) to midnight at the end of Tuesday, December 11, 2018 (Eastern time).</div><div><br></div><div><div>After that, in mid- to late-December, there will be commits to the masters of NEMS and its NCEPLIBS-pyprodutil submodule to add SLURM support for Theia, GAEA, and Jet. In January, those three machines will be unusable to workflows that haven't transitioned to SLURM. Hence, that commit HAS to be in before the end of December. You can expect similar commits to the masters of many other NOAA repositories in the near future for the same reason.</div><br class="m_-6378975555378215461gmail-Apple-interchange-newline"></div><div>Sincerely,</div><div>Sam Trahan</div></div></div>
</blockquote></div>