Re: [LEAPSECS] UT1 offset

Hi Mike, > the system needs an estimate of current UT1 Can you give some references to your observation? I don't recall seeing UT1 mentioned in the first couple of decades of GPS documentation. The system runs on GPS time, the WGS84 coordinate system, broadcast ephemeris including SV clock

Re: [LEAPSECS] speeding up again?

Steve, > We can probably put a lot of the blame onto El Niño That sounds plausible but I'm suspicious of quick and simple explanations. You work at/for a university, near the coast, yes? Can you ping some of your climatology / oceanography colleagues and get data going back as far as they

Re: [LEAPSECS] fb/meta join the leap second haters

> But only from 2000 forward, would be interesting to see it Steven mentioned: > https://hpiers.obspm.fr/eop-pc/index.php > which at the moment is showing a Vondrak filtering "at the moment" is the key; it seems the plot at that URL varies outside the control of the visitor. I captured the

Re: [LEAPSECS] fb/meta join the leap second haters

If you go back I'm sure you'll see it mentioned in the LEAPSECS archive. When you play with 1962+ data there's a clear ~20 year cycle [1] and, more importantly, LOD ends up a bit lower each cycle. So the general pattern looks like 20 year arcs back-to-back on top of a gradual trend of ELOD

Re: [LEAPSECS] 256-week / leap seconds / in the news

defined and managed. BIPM has a good track record of 6 months (~26 weeks) of notice. The official UTC spec is 1 month (~4 weeks) of notice so a 127 week GPS limit is more than adequate. /tvb On 7/25/2021 8:54 AM, Steve Allen wrote: On Sat 2021-07-24T18:50:50-0700 Tom Van Baak hath writ:

[LEAPSECS] 256-week / leap seconds / in the news

In the news: "GPS will broadcast a 0 second leap second in 128 days" https://news.ycombinator.com/item?id=27944776 First, there really isn't a thing called a "0 leap second", but if you've read the GPS ICD wrt leap seconds, you can see why it was posted. Second, it happened once before, in

[LEAPSECS] leap seconds, newspapers, earth rotation

"Atomic clock scientists suggest shortening minute to 59 seconds" This is so bad it's funny. [1] A newspaper headline that's inaccurate by a factor of, just, 100 million. Why? If time had 59 minutes per hour instead of 60 the clock rate would be off by 0.983  And if we had a leap second

Re: [LEAPSECS] "Leap second hiatus"

The article also hit /r/programming with a colorful title. https://www.reddit.com/r/programming/comments/jx6u91/there_has_never_been_a_negative_leap_second_and/.compact /tvb On 11/19/2020 3:59 AM, Tom Van Baak wrote: Today I noticed an unusual number of people suddenly join the LEAPSECS

[LEAPSECS] "Leap second hiatus"

Today I noticed an unusual number of people suddenly join the LEAPSECS mailing list. I tracked down why -- earlier today Tony Finch's blog posting about leap seconds got traction on HN, a well-known tech site. Tony's blog entry is worth reading: "Leap second hiatus"

Re: [LEAPSECS] LEAPSECS Digest, Vol 153, Issue 3

/005112.html /tvb - Original Message ----- From: "Tom Van Baak" To: "Leap Second Discussion List" Sent: Tuesday, April 15, 2014 8:32 AM Subject: Re: [LEAPSECS] Earth speeding up? > I'm not a geophysicist, but I too have noted what Tom reports.  I've attached > a pl

Re: [LEAPSECS] Bulletin C number 60

> Is it time for a LEAPSECS betting pool on when the first negative leap second is deleted? Yes. Or when UTC will stop having leap seconds, yes. Here's betting on leap seconds; in a long thread from 2012: [LEAPSECS] Straw men

[LEAPSECS] Another vote on UTC, facebook

Recent news; another middle-finger to UTC as currently, legally defined. "Building a more accurate time service at Facebook scale" https://engineering.fb.com/production-engineering/ntp-service/ "Facebook Switches to New Timekeeping Service"

Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

>> 2 (or more) Loran-C stations gave you more accurate time. But if you >> know where you are, and since the stations don't move, you can >> manually adjust for signal propagation delay to some extent. This is >> not unlike how one obtains time from WWV or WWVB. > > One of the big issues with

Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

> Within 180 days of the date of this order, the Secretary of Commerce shall > make available a GNSS-independent source of Coordinated Universal Time, > to support the needs of critical infrastructure owners and operators, > for the public and private sectors to access. And I hope by "source of

Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

> I thought of Loran...  but you need 2 stations for time, I thought... 2 (or more) Loran-C stations gave you more accurate time. But if you know where you are, and since the stations don't move, you can manually adjust for signal propagation delay to some extent. This is not unlike how one

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

Hi Hal, It's 2020. How on earth can NTP still not implement UTC correctly, in all cases? Or is it a fundamental NTP design flaw? The Z3801A issue doesn't sound like an NTP problem. This is a known legacy Z3801A f/w or Motorola Oncore problem, yes? Maybe

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

Warner, > Yes. I wish it were clearer that TAI time is a regular radio expression of time. > Here regular radix means that it every day has 24 hours and every hour 60 minutes > and every minute has 60 seconds. I'm not sure it's fundamental to TAI that one must always, or only, use 24x60x60

Re: [LEAPSECS] leap seconds in POSIX

Hal, I see some good comments; did you get the answer you wanted? My take: > Does anybody know of a good writeup of how to fix POSIX to know about leap seconds > and/or why POSIX hasn't done anything about it yet? No write-up. No fix. It's not possible without breaking h/w, f/w, s/w, and

Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug

> However, the current GPS/UTC offset numbers before and after the nearest > leap seconds are still 18/18, so there is no current leap second > announcement, and WNlsf may be ambiguous. Perhaps call it "immaterial" rather than "ambiguous"? The fact that it's 18/18 means no positive or negative

[LEAPSECS] Fw: Second UT1 time server

FYI - Original Message - From: "Judah Levine" To: "Tom Van Baak" Sent: Tuesday, February 19, 2019 9:18 AM Subject: Second UT1 time server > I have installed a second UT1 time server. It will be in Fort Collins, > with address 132.163.97.7 > This will be i

Re: [LEAPSECS] is leap smear legal in Germany?

Steve, et al. Some good history resources: "Special Topic 50 years of time dissemination with DCF77" https://www.ptb.de/cms/fileadmin/internet/fachabteilungen/abteilung_4/4.4_zeit_und_frequenz/pdf/2011_PTBMitt_50a_DCF77_engl.pdf "Time - the SI Base Unit Second"

[LEAPSECS] Of stepping motors and leap seconds

A leap second related story problem. After visit to USNO years ago I wanted to make a leap second desk clock as a thank you gift. The idea was to use a standard 32 kHz quartz clock stepper movement [1] [2] but drive it with a microcontroller such that during a leap second it slows down for a

Re: [LEAPSECS] the epoch of TAI, with no more doubt

> The epoch at which TAI was set is definitely 1961-01-01T20:00:00 UT2 > > https://www.ucolick.org/~sla/leapsecs/taiepoch.html I'm curious how your findings compare with this random link I ran across [1]: https://koka-lang.github.io/koka/doc/std_time_utc.html See especially section "1.3. UTC

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

> If you set your POSIX system clock at TAI minus 10 seconds then > it keeps track of the number of seconds which have been counted > in the internationally approved radio broadcast time scales. So, wait. In order to use Python for any proper UTC processing you have to configure your PC to run

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

> Yo Tom! > > On Tue, 15 Jan 2019 10:50:10 -0800 > "Tom Van Baak" wrote: > > > Nope. All minutes have 60 seconds in Excel. And in Windows. And in > > Unix/POSIX. > > Not quite. Check out "man gmtime" for one way that POSIX repres

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

Jim -- I'm replying via the LEAPSECS list because we love leap second questions here. List -- Jim is a long-time member of time-nuts, works at JPL, and does wonderful stuff. >From Jim Lux: > I'm working with a variety of things which work in UTC or GPS > week/millisecond, so we're doing a lot

[LEAPSECS] leap seconds rarely happen at midnight

Nice take on time zones (applies to leap seconds also): https://xkcd.com/2092/ /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Windows 10 HOME leap second changes

Good questions, and there are many more. Maybe let's see if there's a way to contact the blog posters by email or phone. For something as important as true-UTC timekeeping on Windows, especially at the enterprise level, I'd expect to read formal technical specifications instead of a pair of

Re: [LEAPSECS] more Windows 10 leap details

Part 2 of the blog is just out: https://blogs.technet.microsoft.com/networking/2018/10/24/leap-seconds-for-the-appdev-what-you-should-know/ Note the new, per-process compatibility mode default is a 2 second or ½ second leap smear. Fun times ahead. /tvb

Re: [LEAPSECS] no more listening to leap seconds?

Hi Steve, >From what I understand the same "threat" occurred in 2017 with the FY18 >budget. In the end, the budget ended up greater even than what was asked. So >no cuts were made. Who knows what will happen this time. Still, it's always a >concern; for the staff, for the time service, for the

[LEAPSECS] New GPS Interface Specification IS-GPS-200J is out

See below. Cross post from time-nuts... BTW, have a look at how many bits the EOP parameters have, including DUT1, DUT1/day. That should keep astronomers happy for a while. /tvb - Original Message - From: "Tom Van Baak" To: "Discussion of precise time and freque

[LEAPSECS] comments on UTC

Below are recent threads about UTC on HN & reddit. There's a few comments about leap seconds as well. Read it not so much to learn something new about UTC or leap seconds, but to get a snapshot of real world timing problems that programmers face. "UTC Is Enough for Everyone, Right?"

Re: [LEAPSECS] current / future state of UT1 access?

Reply from Judah below: /tvb - Original Message - From: Levine, Judah Dr. (Fed) Sent: Tuesday, March 20, 2018 6:49 AM Subject: Re: [Non-DoD Source] Re: [LEAPSECS] current / future state of UT1 access? Dear colleagues, The current UT1 time server has 550 users and is receiving

[LEAPSECS] That's why we have leap seconds

Finally, leap seconds get mentioned in xkcd: https://xkcd.com/1930/ Older timekeeping-related postings: https://what-if.xkcd.com/26/ https://xkcd.com/1514/ https://xkcd.com/1061/ /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com

Re: [LEAPSECS] Ramifications of DST -Brooks

Brooks, Clever. The attachment was a bit blurred (color depth, copy/paste?). Here's a full-res version: https://i.imgur.com/nxFWLpn.jpg /tvb - Original Message - From: "Brooks Harris" To: "Leap Second Discussion List" Sent: Sunday,

[LEAPSECS] new delta-T data point

In the news... https://academic.oup.com/astrogeo/article/58/5/5.39/4159289/Solar-eclipse-of-1207-BC-helps-to-date ( https://academic.oup.com/astrogeo/article-pdf/58/5/5.39/20098470/atx178.pdf ) Some other related links: http://rspa.royalsocietypublishing.org/content/472/2196/20160404 (

Re: [LEAPSECS] leap second roundup 2017

> By that logic, one should avoid any interval that includes June 30 or > December 31, since such an interval might include a leap second. John, Right. Exactly. Which is why some systems that need to keep time reliably, or that integrate frequency to get time, avoid leap seconds altogether.

Re: [LEAPSECS] Set your alarms for 2.40am UTC -Brooks

See also: https://www.febo.com/pipermail/time-nuts/2017-July/106316.html /tvb - Original Message - From: "Brooks Harris" To: "Leap Second Discussion List" Sent: Thursday, July 13, 2017 1:07 PM Subject: [LEAPSECS] Set your alarms for 2.40am

Re: [LEAPSECS] Negative TAI-UTC

org> To: "Tom Van Baak" <t...@leapsecond.com>; "Leap Second Discussion List" <leapsecs@leapsecond.com> Sent: Tuesday, February 07, 2017 9:40 AM Subject: Re: [LEAPSECS] Negative TAI-UTC > Tom Van Baak said: >> Yes, of course. This is not the 1960's

Re: [LEAPSECS] BBC radio Crowd Science

> That's where my question is. A GPS receiver would read the UTC metadata > supplied in the GPS signal to generate UTC 23:59:60 from the primary GPS > time, right? Correct. > We see from this discussion there are several ways folks use to > calculate this conversion, but what method to use

Re: [LEAPSECS] BBC radio Crowd Science

> I'm not a GPS expert. IS-GPS-200G is dense. The TAI-UTC value is > signaled, but how its encoded is complicated, and when its updated is > unclear to me. See 20.3.3.5.2.4 Coordinated Universal Time (UTC). Can > anyone speak to that and this topic? What does GPS do? Is it clear? Or > does it

Re: [LEAPSECS] BBC radio Crowd Science

> Also, I'll note that bulletin C says from 0h, which is a time > expressed to only one significant digit. That's a lame excuse to bring up significant digits. Everyone knows that "0h" means midnight, the one at 00:00:00 (as opposed to the one at 24:00:00). Are you now going to criticize a

Re: [LEAPSECS] Negative TAI-UTC

Yes, of course. This is not the 1960's where saving a byte was an all-day decision. The spec is clear. Follow it. While there's sufficient evidence the earth is slowing down over astronomical time due to tidal forces, it's also quite clear that the earth has been speeding up over the past 30

Re: [LEAPSECS] BBC radio Crowd Science

Hi Warner, > But consider TAI and UTC when they were equal, for the sake of > argument. I know they never were, but if we look at what the first one > would look like: That's a nice, clear example. Thanks. > 23:59:58 23:59:580 > 23:59:59

Re: [LEAPSECS] BBC radio Crowd Science

Here's a different take on the situation. Or maybe it's just how someone with cesium clocks looks at the problem. Don't over think what I mean by "clock", "user" and leap second "table" below. Timescale / timestamp conversion in Six Easy Cases: 1) clock sends UTC, user wants UTC - N.B. clock

Re: [LEAPSECS] BBC radio Crowd Science

> It's tricky. Yes. > Bulletin C is pretty clear about when it thinks TAI-UTC changes: Yes. > However, since there isn't any TAI time with a :60 seconds label, Yes. > it doesn't make much sense to have a defined delta for the last UTC second of > 2016. No. The delta is defined "until

Re: [LEAPSECS] BBC radio Crowd Science

> TAI is the fundamental time scale, with UTC derived from it. As TAI > advances, you can calculate UTC by subtracting TAI-UTC from it. At TAI > = 34 seconds, TAI-UTC is 35 and the corresponding UTC time is 23:59:59. > That can be arithmetically correct only if you don't count the leap > second,

Re: [LEAPSECS] BBC radio Crowd Science

> but I've always thought the > instant of the change was unambiguous, and that it was > instantaneous in both cases. Correct. > I've only shown half-second increments, but in the limit, in the > positive case, TAI-UTC would be precisely 35 for every instant of > the second numbered 60, and

Re: [LEAPSECS] BBC radio Crowd Science

> Based on the definition of UTC, it seems to me that there are two > cases, both of which are very simple. For a negative leap second, the > change in TAI - UTC happens instantly at UTC midnight, which is one > second after 23:59:58, when the difference changes by -1. For a > positive leap

[LEAPSECS] seconde intercalaire

An alert reader sent me this note. I have not independently confirmed it. /tvb On December 31, 2016, in Montreal Québec, the municipal police/FD radio communications went into a total shutdown for over 55 minutes. The $74 million digital-encrypted SERAM radio communications system

Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17

> Feb 29th, of course. The print macro just adds "10" to the year field. :-) What would be worse is if Hal worked there 40 years before he got a 10th anniversary certificate. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com

Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17

> I started work at DEC on Feb 29th. 10 years later, I got a fancy certificate > congratulating me on being there for 10 years. Want to guess what date was > on it? Ha! This from the same company that in 1983 wrote my favorite bug report of all time:

Re: [LEAPSECS] alternative to smearing

Oops; typo; sorry; I'm an idiot by a factor of millions. s/seconds/years/ and it should read: 9) Exposing citizens to leap days is near universal. Printed and computer calendars have no trouble with that extra day. Almost every child learns about leap years during their schooling. Some people

Re: [LEAPSECS] alternative to smearing

> There's a big difference between these two: February varies in a fixed, > regular manner, whereas UTC days are unpredictable. The Gregorian > calendar is of the arithmetic variety, whereas UTC is an observational > calendar. UTC is qualitatively more difficult to handle. > > -zefram Agreed.

Re: [LEAPSECS] Leap seconds ain't broken

> There are subtleties to timekeeping. Removing leap seconds wouldn’t remove > the subtleties, rather it would promote them to significantly more > importance, perhaps “breaking” even more software and systems. > > Rob Now that several dominate vendors of computing are using smeared leap

[LEAPSECS] JD & MJD, UT1 & UTC

Now is a good a time as any to bring up an issue I've been meaning to ask. My understanding is that JD has always been a day count, based on rotations of the earth. So the timescale from which JD is calculated is UT1 (not TAI or UTC). JD is widely used in astronomy. Presumably when JD is

Re: [LEAPSECS] Greetings from an intercalary second

Line 55 of my raw headers has your leap second: 1 Return-Path: 2 Delivered-To: tvb-leapsecond:com-...@leapsecond.com 3 X-Envelope-To: t...@leapsecond.com 4 Received: (qmail 73506 invoked from network); 1 Jan 2017 00:00:09 - ... 00049 for

[LEAPSECS] Time math libraries, UTC to TAI

Eric, and time nuts -- A very nice set of questions and an interesting application. In fact it's so time nutty that I'll send it over to the LEAPSECS mailing list, which is the niche of time-nuts where we deal with issues of TAI, UTC and leap seconds. You can pick up your replies there.

[LEAPSECS] private smear goes public

I'm surprised no one has posted this news yet: "Making every (leap) second count with our new public NTP servers" https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html /tvb___ LEAPSECS mailing

Re: [LEAPSECS] A standard for leap second smearing

NTP is designed to disseminate the SI second and a UTC timestamp. If you want a completely different timescale (e.g., UT1, or some smeared variant of UTC) it seems like this could be part of NTP, not some opaque hack below or above NTP so as to "fake out" ancient or hardcoded assumptions of

Re: [LEAPSECS] Bloomberg announced its smear

Harlan, Get down to the details about PC clock frequency instability and OS measurement jitter and I suspect you'll find that cosine vs. triangle is a red herring. I would almost vote for random smear. The purpose of a smear is to obscure the extra / missing second in UTC. If someone

Re: [LEAPSECS] Bloomberg announced its smear

> Hm, IMO the advantage of the initial smear approach (24 hours before the > leap second) is that smearing is finished as soon as the leap second has > occurred, so the beginning of the next UTC day /hour / minute is accurate. Martin, I suspect your idea only works in cases when the time server

Re: [LEAPSECS] A standard for leap second smearing

> Does it matter that in Seattle the smear occurs at 5:00 in the afternoon, > local time, Richard, When using local time, it's one step more complicated; in Seattle: 4:00 PM PST is when a leap second occurs in Winter (e.g., December 31) 5:00 PM PDT is when a leap second occurs in Summer

Re: [LEAPSECS] Bloomberg announced its smear

Brooks, > The Microsoft Azure approach of moving the leap second to local midnight has > been discussed. > I suppose you mean at LEAPSECS? If so I've missed that and be interested in > the reference. > I'd be interested in any other discussions of it as well. There are several dozen posts in

Re: [LEAPSECS] Bloomberg announced its smear

Stephen, > As I've been saying for years, what we need (desperately) is a > standard for smearing, aka 86400 subdivision days. But that's part of the charm in smearing -- that there's no one way to do it, and you're free to modify it as you wish. > My preference is UTC-SLS, but I don't really

Re: [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

- From: "Martin Burnicki" <martin.burni...@burnicki.net> To: "Tom Van Baak" <t...@leapsecond.com>; "Leap Second Discussion List" <leapsecs@leapsecond.com>; "Discussion of precise time and frequency measurement" <time-n...@febo.com> Sen

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

es, N8ZM > > > -Original Message- > From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak > Sent: Thursday, July 21, 2016 1:28 PM > To: Discussion of precise time and frequency measurement <time-n...@febo.com> > Cc: Leap Second Discussion List

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Steve Allen wrote: > This idea pushes extra complexity into every implementation of low > level kernel-space software, firmware, and hardware. That's nice as a > policy for full employment of programmers, but it's hard to justify by > any other metric. Instead those low level places should be as

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Time to mention this again... If we adopted the LSEM (Leap Second Every Month) model then none of this would be a problem. The idea is not to decide *if* there will be leap second, but to force every month to have a leap second. The IERS decision is then what the *sign* of the leap second

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Hi Mark, Three comments: 1) I recall this is a known problem in the Z3801A status reporting, and possibly other GPS receivers of that era as well. It stems indirectly from a change years ago in how far in advance IERS and DoD were able to update the leap second info into the GPS

[LEAPSECS] Hawking / PBS TV show about Time

Slightly off-topic, but this may be of interest to some of you who aren't also on the time-nuts list. Tonight, Wednesday evening (May 18) look for a TV show on National Geographic or PBS called "Genius by Stephen Hawking". Episode 1: Can We Time Travel? I mention this because I may be in this

Re: [LEAPSECS] Kinemetrics/Truetime WWVB model 60-dc?

Hi Rob, > No answer yet from Time-nuts. There were several replies to your post to time-nuts. The thread is at: https://www.febo.com/pipermail/time-nuts/2016-April/097575.html The short answer is that your 60-DC receiver will no longer work. There are several ways around this but none of them

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

> Hi Tom, > > The values presented in the 2004 Morrison and Stephenson paper are > already smoothed using a series of cubic splines and a parabola prior > to -700. See their table 1 and its discussion. The authors > recommended simple interpolation between the listed years, so I did > that

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

> I neglected to mention the URL for my revised paper. It is > > https://www.systemeyescomputerstore.com/proleptic_UTC.pdf > >John Sauter (john_sau...@systemeyescomputerstore.com) Hi John, Given that your pUTC is pure fiction, though possibly useful fiction, did you consider a simple

[LEAPSECS] World map of the difference between solar and clock time

Very nice solar vs. local time map: http://blog.poormansmath.net/images/SolarTimeVsStandardTimeV2.png Article: http://blog.poormansmath.net/the-time-it-takes-to-change-the-time Comments: https://news.ycombinator.com/item?id=10319681 /tvb ___ LEAPSECS

Re: [LEAPSECS] countdown to WRC-15

Hi Harlan, Look back in the archives for LSEM (Leap Second Every Month) discussions. The idea was to have a leap second at the end of every month, always. It would force all precision timing systems to correctly deal with leap seconds, positive as well as negative. DUT1 would remain 0.7 s. By

[LEAPSECS] Why the Greenwich meridian moved

For those of you that have been at this a while, the exact location of zero longitude is very interesting. Not just for astronomy, but also in the history of precise timekeeping. An alert reader pointed me to a great article, just published (and free PDF). Why the Greenwich meridian moved

[LEAPSECS] GLONASS leap second

Richard, or Martin, or anyone, What's the latest on how GLONASS handles leap seconds? I remember years ago receivers (or the SV itself) reset their timescale across the leap event -- because they use UTC(SU)+3h (Moscow local time) as their system time and not a leap-less, timezone-free

Re: [LEAPSECS] leap second festivities?

What are people’s plans for the day? Some ideas: http://leapsecond.com/notes/leap-watch.htm For the previous leap second in June 2012 I happened to be on a family vacation on a remote beach in the southern hemisphere. I built a sundial out of driftwood and traced the shadow

Re: [LEAPSECS] leap second festivities?

Some clocks are right twice a day. This one once every few years: http://leapsecond.com/images/CD47-235960.jpg /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] a new type of negative leap second

The folks at http://www.timeanddate.com/time/leapseconds.html have a leap second animation on the top right side of the page. I'm not sure how it displays for you, but attached are some screen shots on my end. Cute. /tvb___ LEAPSECS mailing list

Re: [LEAPSECS] Google, Amazon, now Microsoft

Tom Van Baak said: On a positive note, this means one could actually experience more than one Windows non-leap-second on June 30. Maybe this year I should try to celebrate the leap second twice, in Mountain and in Pacific time. Time to pull out the road map. Why stop with Mountain

Re: [LEAPSECS] Google, Amazon, now Microsoft

On 31 May 2015, at 03:28, Rob Seaman sea...@noao.edu wrote: DST changes at 2am in the US and 1am in the EU. That is 01:00 UTC which is 02:00 standard / 03:00 summer time for most of the EU. Tony. Tony, that's my understanding too, that all DST changes always occur at 2am local time,

Re: [LEAPSECS] Google, Amazon, now Microsoft

is +/- 2 hours instead of +/- 1 hour? I ask because the still-in-development PE (phase encoded) WWVB format appears to allow for such a (non US legal) transition. I can't quite tell if it's a bug or typo or spec. /tvb - Original Message - From: Rob Seaman sea...@noao.edu To: Tom Van Baak

Re: [LEAPSECS] Google, Amazon, now Microsoft

You'll need a faster car. Or a plane. Maybe we could get the guys on the space station to try it? Hi Brooks, On the equator, timezones fly by about 1000 mph (earth diameter is ~25000 miles, day is ~24 hours). So that excludes cars and commercial planes. Even up here at 45 degrees latitude,

Re: [LEAPSECS] Google, Amazon, now Microsoft

Perhaps one should point out that local midnight is pretty much the worst possible time for astronomers to accommodate such a change? Hi Rob, Oh, you're such an old earth+photon guy. Ask any space probe, neutrino, or gravitational astronomer if they share your sleep problem. ;-) I understand

[LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News

https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ https://news.ycombinator.com/item?id=9567761 /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] GPS week-number data field size (was W1K GPS rollover for some time servers)

voltages were 6.3 VAC (filament) and ~250 VDC (plate B+), there were no quartz wrist watches, or airbags. Evolution is ok. It might even be natural. /tvb - Original Message - From: Peter Vince To: Tom Van Baak ; Leap Second Discussion List Sent: Tuesday, May 05, 2015 1:20 AM Subject: GPS

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

The tabulations of the times of emission of radio broadcasts of UTC were given in units of, and with an accuracy of 0.0001 s; i.e., 100 microseconds. The tabulations of the intercomparisons between the time scales in those laboratories are given with decimals to 0.1 microsecond, or 100

Re: [LEAPSECS] W1K GPS rollover for some time servers

As seen at http://lists.ntp.org/pipermail/hackers/2015-May/006866.html and also as experienced at Keck Observatory last night, some models of GPS time servers just did their firmware's W1K rollover, so those are saying the date is 1995-09-17. But the leap second is, inappropriately,

Re: [LEAPSECS] W1K GPS rollover for some time servers

As seen at http://lists.ntp.org/pipermail/hackers/2015-May/006866.html and also as experienced at Keck Observatory last night, some models of GPS time servers just did their firmware's W1K rollover, so those are saying the date is 1995-09-17. But the leap second is, inappropriately,

Re: [LEAPSECS] LOD and gravity connected ?

Thanks for the link. I see the PDF is free this time. /tvb - Original Message - From: Poul-Henning Kamp p...@phk.freebsd.dk To: Leap Second Discussion List leapsecs@leapsecond.com Sent: Wednesday, April 29, 2015 2:32 AM Subject: [LEAPSECS] LOD and gravity connected ?

[LEAPSECS] Question about UT1 and the IERS Reference Meridian

BTW, this excellent question came to time-nuts yesterday; does anyone here have a definitive answer for Mike? Thanks, /tvb - Original Message - From: mflaws...@cox.net To: time-n...@febo.com Sent: Tuesday, April 28, 2015 8:06 PM Subject: [time-nuts] Question about UT1 and the IERS

Re: [LEAPSECS] UTC fails

Steve, And UTC has failed miserably. POSIX says UTC has no leaps. Google says UTC has occasional days with stretches of seconds which are of varying lengths. De facto, there is no single UTC time scale. Right! And many more examples of UTC fails -- the RTC of any unix computer. Any windows

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

Brooks wrote: Many timekeeping systems seem to be designed for only indicating now counting forward, including NTP, POSIX, and PTP, taking short-cuts to avoid supplying full Leap Second and local-time metadata. Warner wrote: A clock doesn’t need to know its past. But a time scale is more than

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

leap59 and leap61 are Leap Second announce signals, set 12 hours prior to the insert. There has been discussion about when the official announcements and expiration should be announced. ITU Rec 460 says ...at least eight weeks in advance. PTP can't do that, a point to keep in mind.

[LEAPSECS] BeiDou Numbering Presents Leap-Second Issue

http://gpsworld.com/beidou-numbering-presents-leap-second-issue/___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has no flag defined to announce a negative leap second, so there would be major problems if one had to be inserted. Both WWVB and DCF-77 have a single

Re: [LEAPSECS] final report of the UK leap seconds dialog

Hi Stephen, You're not looking in the wrong places. In fact there is no need to look at all. Local time is conventionally (legally) an offset from UTC and so if/when UTC steps so does local time. There is no need for a local decision or international standards in this regard. Everyone living

Re: [LEAPSECS] final report of the UK leap seconds dialog

Many aspects of local time or civil time are left to common practice which is not good enough to expect uniform inter-operable implementations. Brooks, can you give some examples? We here concentrate on discussions of UTC and Leap Seconds, which is foundational, yet obviously local time

  1   2   3   >