[LEAPSECS] UT1 offset
>>> . Please keep DUT1 less than 100 seconds. >> They /really/ dont want to ever see a leapsecond or leapminute, do they ? > I'd love for them to have 6 digits for the offset.. .99. Why try to make that field big enough? Why not just drop it? Who uses DUT1 via radio? Who will be using it 50 years from now? Is it needed for anything other than navigation and astronomy? I assume astronomers will have a network connection. Do ships listen to WWV or similar to get DUT1? How many ships are big enough to need DUT1 for navigation yet small enough that they don't have GPS? Another option would be to drop the high digits. Fill them in with firmware the same way that software now fixes GPS WNRO glitches. (That would take an extra line of code if you have to go both forward and backward.) 2 digits of seconds would be good for 50 old-leaps either way. Or you could make it 75 one way and 25 the other... - I poked >Who uses DUT1?< into Google. It found: https://www.ucolick.org/~sla/navyls/0907.html Who uses DUT1? From: Tom Van Baak Date: Sat, 30 Jul 2005 10:18:42 -0700 The by-thread index doesn't show that thread. Google found Steve Allen's reply. https://www.ucolick.org/~sla/navyls/0900.html Re: Who uses DUT1? From: Steve Allen Date: Sat, 30 Jul 2005 23:31:52 -0700 Both are in the by-date index. Steve discussed astronomy and navigation. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap seconds have a larger context than POSIX
tvb said: > There's no ambiguity. Those are just bugs. No software should depend on more > than 1 month notice of a leap second and no software should be fooled if the > notice is months or even years in advance. There are plenty of quirks in ntp code along that line. The APIs don't have an explicit when. The NTP-Kernal API for leap-pending is leap-tonight. You have most of the next day to turn it off. The leap-pending on the wire is leap-at-the-end-of-this-month. I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was June or December. It's a hack, but it gets the job done and the code wasn't setup to ask it when the leap would happen. tvb said: > If you're writing a FAQ or best practices guide stay in touch. I have a > semi-technical leap second report in the works. UTC is actually very simple; > but it's been complicated by untold levels of bad assumptions, bad > execution, and bad prose. Are you going to say anything about POSIX? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap seconds in POSIX
t...@leapsecond.com said: > I see some good comments; did you get the answer you wanted? Nothing off list, so you have seen everything that I saw. I was hoping that there would be a good white paper or blog that discussed all the possibilities that have been considered and explained why they were rejected. --- Probably crazy idea dept... Has anybody considered having time_t and the kernel keep smeared time? The idea is that you can convert from smeared time to TAI or UTC with leaps. So a few new library routines should be enough for the few people who care about leap seconds. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] leap seconds in POSIX
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? I assume the basic idea would be something like switch the kernel to use TAI rather than UTC and implement conversion in some library routines. There is a discussion on the IETF ntp list with typical S/N for this topic. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Running on TAI
> The trick is to find a source that will set a POSIX system to TAI, and then > to avoid the gotchas that happen when such a system interacts with other > POSIX systems. What do the systems that point telescopes use for maintaining their system clock? Do they use NTP or a special program that listens to GPS or a local Hydrogen maser or ...? Some GPSDOs have the option to return GPS time rather than UTC. GPS is a fixed offset from TAI. So it's easy to run your system on TAI. All it takes is a little sysadmin hacking, no programming. You won't easily get redundancy from checking with other NTP servers. If you have several friends running similar systems, you could set up a private NTP network. With some work it would be reasonable to setup a ntp server that took in UTC but gave out TAI. That would be similar to the way leap smearing works. We could use a separate port number to minimize confuzion. As far as I know, the kernel doesn't know anything about what type of time it is maintaining. It just sets the clock as directed and goes tick, tick, tick. The trouble is with the time conversion routines. They all assume a time_t is UTC. So if you ran your system on TAI, all your log files would be off by 37 seconds. How hard would it be to insert a wrapper in front of the time conversion routines? The idea is to rename all the current time conversion routines from foo to foo_utc and implement foo_tai that concerts between UTC and TAI. It would need a list of leap seconds. The default implementation of foo would call foo_utc but an environment variable or such would switch to using foo_tai. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Windows Server 2019
> I think it does matter. I, for one, would be interested in credible > explanation of the "smears", and, if these have been coordinated, by whom, > and how. Here is Google's documentation: https://developers.google.com/time/smear We encourage anyone smearing leap seconds to use a 24-hour linear smear from noon to noon UTC. We plan to use this smear for all future leap seconds. Amazon uses this smear in AWS. > What I'm hoping will appear is a document that can be treated as a standard > (preferably at a formal standards body of some kind). I don't think you will get more than the above. The fundamental problem is that POSIX doesn't admit to the existence of leap seconds. Smearing on NTP is a hack. It just happens to be a very useful hack. It covers many many systems. People are unlikely to work on a document for something that can be described in one line of text, especially when all the people who care have already agreed. The whole point of smearing is so that most users don't have to do anything. Why do you need documentation for that? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Windows Server 2019
> As a IT professional, and author of date/time libraries, I cannot stress
> enough how much a standard is needed here. We are going to have both UTC
> (with leap seconds) and systems that smear ("UT-Smear") and there is
> currently no agreed way to define the latter or move from one to the other. I
> strongly suspect that Microsoft is going to have to define a smear in order
> to meet old APIs, but this really should be something well defined by a
> standard, not invented by a company.
I think there is a semi-standard emerging for NTP.
There are several big companies running smearing servers. I think they have
all agreed to use the same parameters. I think that's linear over 24 hours,
12 before the leap and 12 after. I'll dig deeper if it matters.
--
These are my opinions. I hate spam.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] UT1 via NTP
I haven't seen any comments from astronomers with info on how accurate they need UT1. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] UT1 via NTP
Gary said: > It would be simple to mod an NTP client to download and apply that > correction. No need for a new protocol. The question is how many users are there. If there are only a few, then they should all just download the official IERS version or one of the clones. If there are enough users so that the downloads would be a serious load, then a lightweight protocol like NTP makes sense. But NTP isn't very accurate unless there is a good network connection which usually means close geographically. Thus, if you want good UT1, you either need lots of servers so most users can find one nearby or we need a new protocol that just distributes the offset. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken
leapsecs-requ...@leapsecond.com said: > Right, that's where I say its incredible nothing was done since 1972. The > Leap Second history is fundamental, and it seems to me an obvious missing > link. How could it have gone ignored all this time? Back in the old days, computer clocks weren't accurate enough to care about leap seconds. In the early 80s, the NTP equivalent at Xerox was only good to a second and it was only used at boot time. By the time computers and networks (and a few geeks) were good enough to notice, it was too late. Anybody know when NTP supported it's first leap second? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] alternative to smearing
>> Are there any performance critical chunks of code that want to wait until N >> years from now? I doubt it. > With due respect, that's a crappy attitude to getting something right. You > want to have one interface that always works that's easy to use and schedule > with. If you don't have that, then your software is more likely to break. > IMHO, that's yet another example of the "it's only a second" attitude that > keeps us from having nice things like a working UTC implementation on Unix. I think there are two different types of wait. One is the simple wait N seconds. The other is wait until a specified date-time, say a month from now. They really are different so I don't see how to make your "one interface" work. I was assuming that the API to the kernel was wait N seconds. If you want to schedule something for a month or year from now, I was assuming that there would be a library routine that took a Y/M/D-H/M/S type format and figured out how many seconds to wait. Somebody else mentioned performance critical. I was trying to ask if there was anything performance critical about the library code that was translating from a calender style date-time to seconds-to-wait. I hate bloat and crufty code as much as anybody. A library routine to handle all the quirks of leap seconds and leap years and daylight savings seems reasonable to me. But maybe I'm overlooking somethings, so that's why I asked. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second smearing test results
>> I don't think the client pays any attention to that field in the packet. > Hm, when Harlan made the proposal then he said the client did. You are right. There is some code in there. Thanks. It might be interesting to see what the RFC or book says about that area. I'd like to understand what it does in the non-leap case and/or why. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] alternative to smearing
[do something N years in the future] > Except that's not how things are programmed. Programming it that way would > be very inefficient in a part of the kernel that has to be ultra-efficient. > Since you don't know how many seconds it will from now, you can't schedule a > timeout. The current setup of UTC doesn't let me know how many seconds it > will be in the future. People can talk about it, but computers don't always > store things that way. ... Are there any performance critical chunks of code that want to wait until N years from now? I doubt it. If I ask for 6 months rather than a few years, then you also have to consider daylight savings. Actually, you have to consider it anyway. Congress might change the start/stop times again and your wait-until might hit one of them. I think that means that if you want to schedule something a long time in the future specified as date and time rather than seconds from now, you have to wakeup a bit early and recompute how long to wait. For leap seconds, the bit early has to be a few months, depending on how long it takes you to update your leap file. For daylight savings, I don't think you can predict a value of a bit early. Congress isn't dependable. How far in advance were the last daylight savings changes announced? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17
> 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 are even born on a leap > day. 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? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] alternative to smearing
> 1) The leap day in February can be handled by any isolated or autonomous > clock or timekeeping system. A leap second can only be handled with periodic > direct or indirect communication with IERS, or manual intervention with the > likes of keyboard input or toggle switches. For secure or embedded systems > this is a huge issue. If a system is isolated, does it matter if its clock knows about leap seconds? I could imagine that "isolated" meant nothing goes in for security reasons, but then time doesn't go in either. So maybe you allow GPS to go in the back door, but that has leap info. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second smearing test results
> Unfortunately not. More tests to be done. Especially the cases where the > server sends "poll 4" to its clients during the smear interval. On the one > hand this seems to have an affect on the client, in that the client's poll > interval decreases more than without it. On the other hand, why does the > client poll only decrease to 6, even though the server suggests 4, and why > is the client increasing its poll interval when the frequency seems to > become "stable", ... I don't think the client pays any attention to that field in the packet. It reduces its polling interval when things change faster/farther than expected and increases it when things are working smoothly. (Sorry for using non-technical terms.) > If the client has a long poll interval and/or polls only lately next time > after smearing has stopped the time offset due to the changed frequency has > increased much more than with a client that polls next time shortly after > smearing has stopped. Right. Google's smear is off by 13.9 ppm. At 1000 seconds, that's 14 ms worst case. But how early do you want to poll? If the client asks right after the smearing stops, there won't be any accumulated offset so it won't see any error and won't do anything. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)
i...@bsdimp.com said: >> Could that be solved with 2 functions in the API, one for N seconds >> from now, and a second for at some future date/time specified in >> Y/M/D/H/M/S format rather than something like a time_t? > Only partially (meaning only assuming every day has exactly 86400 seconds). > These operations are possible today, since the former is += and the latter > is timegm(), sorta, but neither groks leap seconds. And if you were to > transition to a TAI world, then you'd not be able to implement the latter > for a TAI time of the UTC time at some Y/M/D/H/M/S past the end of the next > six month boundary, since it is impossible to have that knowledge. Sorry, I didn't fully explain what I was trying to suggest. Suppose the kernel keeps time in TAI and has a call to wait N SI seconds. Suppose I want to wait until some UTC date/time more than 6 months in the future. A library routine doesn't have to compute how many seconds to wait right now. It can break it down into chunks. Wait until the current leap file expires, then try again using the new one. ... -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)
> One could imagine having a more complicated structure that could cope with > the inherent ambiguity in future times. I can't say "schedule an event > exactly 1 year from now" for example without it. I need additional metadata > around to know if I want it to happen at the same time of day on the same > date or if I want it to happen after than many seconds have elapsed. You > can't convert a putative UTC time to TAI time until you are within 6 months > of that time (the current announcement schedule) because if you try to > compute that time too far in the future, it will change. ... Could that be solved with 2 functions in the API, one for N seconds from now, and a second for at some future date/time specified in Y/M/D/H/M/S format rather than something like a time_t? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Time math libraries, UTC to TAI
>> ...There's other systems that 'freeze' time during the leap second, >> only incrementing it by a tiny fraction for each gettimeofday call. > Do you know which systems those are? I haven't found any of them. I know > Dave Mills talks about them. I've heard that Linux implemented that scheme > once, but later removed it. NetBSD did it that way for the leap at the end of 2005. http://users.megapathdsl.net/~hmurray/leap-second/leap-second.html Wait a week and we should have some up to date data. > I have never seen a system that froze the clock. That would be most > unhelpful behaviour, making it impossible to recover true UTC. The clock isn't frozen. It just advances very slowly, taking tiny steps whenever anybody reads the clock. That lets you use the clock for Unique-IDs and compare times to see which of two events happened first. It's a hack, similar to smearing over many hours. Time doesn't go backwards. Except for the semi frozen second, the clock is accurate. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] private smear goes public
> That's another problem with leap seconds: they are irregular and there's no > standard way to get the leap second info reliably (though there are sources > of data on the internet that are changing that if you are connected. There is a plan to distribute a leap second file as part of the time zone data base. It's in Debian and Ubuntu: /usr/share/zoneinfo/leap-seconds.list and FreeBSD: /var/db/ntpd.leap-seconds.list Looks like they packaged it with ntp rather than zone info. I don't see it in Fedora. There is one in Raspbian, but it's an old version. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] private smear goes public
> Could someone provide an introduction to how the rates of these reference > clocks are adjusted? What's going on inside the black box? ... > Can the frequency of the crystal (or whatever) oscillators be adjusted by > applying some bias voltage? It's all done by software. Each CPU has a nominal clock frequency and some counter that ticks at that rate. The kernel timekeeping routine does something like: newcycles = readMagicRegister() cycles = newcycles - oldcycles oldcycles = newsycles newtime = oldtime + cycles*timePerCycle oldtime = newtime The trick is that you need a lot of low bits in timePerCycle. It's not simple integer arithmetic. The kernel has a system call that ntpd uses to tweak the value of timePerCycle. It's the ntpd drift parameter. Normally it's used to correct for the crystal being slightly off from the nominal value due to manufacturing tolerances. It also tracks minor changes due to temperature and aging. Fudging it slightly to implement a leap smear fits well within reasonable numbers as long as the smear is spread over a long enough time slot. 20 hours is long enough. ntpd can't tell the difference between a leap smear and a temperature shift. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Time Synchronization in Financial markets
> Meantime there is no standardized way to keep the Leap Second tables > automatically updated to begin with. It's being distributed with the time zone data. Hopefully, all the major distros/OSes will include it by the end of the year. (Don't hold your breath.) >From Debian jessie -rw-r--r-- 1 root root 10384 Feb 22 2016 /usr/share/zoneinfo/leap-seconds.lis t > Not being a traditionalist myself, I don't feel that there is anything wrong > with 23:59:60 as a label for a particular second. Unfortunately, POSIX says that second doesn't exist so a lot of the software you use can't handle it. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bloomberg announced its smear
tvb said: > Smearing is fine. It's a practical solution to an intractable problem. But > forcing everyone to implement it the exact same way misses the point. You > can't create a standard for your favorite set of time applications and then > try to force it upon everyone else's time applications. I think that's misleading. If you are going to smear, there are a lot of problems that go away if everybody uses the same parameters. Unless there are reasons to select one value over another, selecting one with a coin flip is generally better than running incompatible implementations. This is still early in the deployment cycle. It may be appropriate to experiment. Unfortunately, leap seconds don't happen often enough to make that an useful approach to gaining experience. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
s...@ucolick.org said: > 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 simple as possible, and > that means making the underlying precision time scale, and thus any > broadcast distributions of a precision time scale, as simple as possible. Has anybody done any serious thinking about fixing the POSIX problem? I assume the first step would be to have the kernel keep time in a non leaping time scale. Is UT1 the obvious choice? Would we need a version of ntp that used that time scale? (or some non-leaping time scale) I assume the file dates could be fixed with a flag day and one pass over the whole file system. I think the hard part would be time-stamps in network protocols or data bases. Consider tar files or rsync. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Seconds schedule prior to 1972
john_sau...@systemeyescomputerstore.com said: > I take your point. How about a format with three different types of > lines: comments, data lines, and keyword=value lines. The data lines > contain julian day number, DTAI at the end of the day, and year-month- > day. The keyword=value lines contain such things as start date, end > date, expiration date and checksum. Keyword-value is good. You may want to allow comments on the end of content lines. The julian-day and year-month-day look redundant. I wouldn't do that. It leads down the rathole of what to do if they don't agree. Don't over engineer it. Write some sample code. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Seconds schedule prior to 1972
john_sau...@systemeyescomputerstore.com said: > With that much complexity, perhaps it should be formatted as an XML file. > Do you think that would be reasonable? If so, how would you > format it? If you want an useful opinion you should probably ask the people who might use it. I think of XML as bloat and avoid it whenever I can. (Same for HTML in email.) That file isn't actually complex. There are only a few different types of data lines and within each type, there aren't any variations. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Seconds schedule prior to 1972
> What do you think? Sounds reasonable. I think the important points are some sort of checksum to help catch mangled files and an expiration date if you expect the file to cover modern leap seconds. If you expect that there really will be multiple variants of the data, you might put an ID into the file, maybe the author and year, any string that will be unique in that context. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Seconds schedule prior to 1972
john_sau...@systemeyescomputerstore.com said: > I agree that publishing a table is a good idea. Any suggestions > on the format? ntpd knows how to parse a file with times when leap seconds did and/or will happen. Sample here: http://www.ietf.org/timezones/data/leap-seconds.list It's got enough comments to explain what's going on. It's using NTP time - relative to 1 January 1900, 00:00:00 You could use the same format with negative numbers for before 1900 or pick your own starting point. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Seconds schedule prior to 1972
> Think about the code that some poor programmer is going to have to write as > they read your PDF. Instead of an if-else-if sequence that goes on for > pages, is there a simpler way to generate pUTC? I mean, no human is going to > read your PDF and manually go through the guidelines you present. So maybe > think of the code first instead of the prose. The if-else mess can be turned into a loop scanning a table. (or binary search) If the table format is anything sane, you could publish the table someplace public and give it a name. If somebody comes along with a better proposal, they can publish their table. Any paper that uses this technique needs to specify which table they use. I think there is already something similar for correcting carbon-14 dates. If you publish a paper using C-14 dating, you specify which corrections you used. https://en.wikipedia.org/wiki/Radiocarbon_dating#Atmospheric_variation -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] embedded data loggers?
> Have been rummaging around looking at Arduino and/or Raspberry Pi hacks, but > the former seems under-powered to run a full NTP instance and the latter is > not real-time. Surely there must be an off-the-shelf dohickey that can > return (via a unix-style service, for instance) a reliable ~millisecond > timestamp corresponding to a trigger? The Raspberry Pi supports PPS inputs. I haven't investigated the details, just followed the cookbook for setting up a GPS board that sits on top of the Pi. In case it's not obvious, you can repurpose the PPS infrastructure for other hacks. The interrupt routine grabs the time which user code can read at its leisure. I use it for watching the time from the power line. Real-time isn't an issue at the milisecond level. ntpd works fine on a Pi. There are several major versions of the Pi. The new one is significantly faster. Beware, GPIO inputs are (only) 3.3V. If you are interested in fine print, one weak link in the Pi is that the Ethernet is connected via USB which adds a hardware polling delay, aka jitter. There is a flag to eliminate the batching delay. Round trip time from a PC as shown by ntpq is under 0.6 ms to an old Pi and under 0.4 to a new Pi. You can try things on a PC with a serial port. The normal setup is PPS on pin 1, DCD. Linux PPS also works on USB serial adapters. They use slow USB (1.0?) so the polling rate is 1 ms, but aside from that it works. Linux has a hack where you can read the PPS info from a script. root@rp7:/home/murray# cat /sys/devices/virtual/pps/pps0/assert 1452499255.08059#3592986 root@rp7:/home/murray# The stuff before the # is the time of the last pulse, seconds and nanoseconds. The stuff after is the count of pulses since the PPS device was setup. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] What happened in the late 1990s to slow the rate of leap seconds?
There is a nice graph here: http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html Was there a geological incident that explains things? We didn't have any leap seconds for 7 years. From the leap second file: 3124137600 32 # 1 Jan 1999 3345062400 33 # 1 Jan 2006 There is another warp in the graph in the late 1980s. Things slowed down for several year, but not as dramatically as the early 2000s. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Why the Greenwich meridian moved
That story made NPR yesterday. The audio is only 30 seconds. GPS Locates True Greenwich Meridian Line http://www.npr.org/2015/08/14/432192377/gps-locates-true-greenwich-meridian-li ne When GPS arrived 30 years ago, the real prime meridian was revealed. It's 334 feet to the east, and it's currently marked by a trashcan. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] EBML: yet another date format?
Looks to me they mean 128 bits? How did you get that? supported by a signed 8-octet integer in nanoseconds centered on 8*8 is 64. I didn't see anything about using two of them. POSIX uses 32 bits of seconds and 32 bits of nanoseconds. That will wrap in 2038. Using all nanoseconds gets a few more bits so the overall range will be a bit bigger. (Whether it's enough bigger is another matter.) -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 105, Issue 9
Mon Jun 22 21:00:29 UTC 2015 Mon Jun 22 21:00:54 UTC 2015 I had hoped this would be an easy way to find TAI, but it looks like I'll have to parse the leapsec list. You can get the TAI offset by converting those two strings back to a time_t. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
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 and Pacific? There are many more time zones to try. If you don't capture the event you want, just change the time zone and try again. You have an hour to tweak things and get setup to try again. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News
Warner Losh said: One has to wonder, though. UTC is the standard. Why do we need another standard to subvert the original standard if the original standard were easy to implement correctly? Surely the existence of these ?smeared? timescales points to a fundamental flaw in the method we?ve chosen to keep atomic and solar time in sync? I think the problem is conflicting standards. POSIX doesn't agree with UTC. Are there any examples of buggy standards with a huge installed base getting fixed? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] problem fetching Leap_Second_History.dat ?
http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat Which is a URL redirection (nominally ?moved temporarily? ... Haven?t looked very far under the hood yet, so could certainly be something else entirely. It redirects to https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat (same with http=https) The S requires encryption. It's a lot more complicated so I'm not too surprised that some software can't follow that redirection. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] My FOSDEM slides
GPS time (or whatever) is fine in closed projects/environments, but IMO a UTC and TAI are the global time scales, while GPS is specific to the U.S. Since GPS time is a fixed offset from TAI, it's easy to convert. My vote would be to use TAI rather than GPS wherever you are trying to avoid leap seconds. (If you are dealing with GPS itself rather than time in general, it might make sense to use GPS time consistently throughout a project.) -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The definition of a day
So, let us suppose the year 2600 is when the drift reaches the annoying point, and let us suppose the EU is still in existence. By then the sun will reach its highest point at about 12:45 UTC. So at this point the EU announces (a few years ahead) that the normal autumn shift back of the clocks will not happen. ... Dealing with local time changes as you cross borders is something people are used to, as is the fact that the amount of change varies both within the year and from year to year. So there's nothing new for people to get used to. It's not as simple as just skip an hour shift. I'm in the US. We are used to dealing with hour shifts in the spring/fall. But the system has had years to get used to that. If you skip one, then all sorts of things need to get adjusted. I'm thinking of things like schools starting in daylight so there are fewer traffic accidents. It doesn't matter if they start at 8AM or 9AM or 7AM, but if they have been starting at 8AM and you adjust the clocks by an hour you need to adjust the starting time by an hour to get back to where you want to be. It would be an interesting exercise to collect all the issues like that. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Future Leap Seconds
If Bulletin C contained a table of leap seconds for the next 6*N (for hopefully large values of N), a significant hassle to leap second implementation could be avoided as 6*N would approach the useful life of an embedded system for relatively small values of N and the embedded system wouldn?t have to guess based on incomplete or contradictory information like it does today (especially if this system isn?t connected to the internet). ... I don't understand this case. Can somebody give me an example of a system that needs accurate time and isn't connected to a place where it can get leap info? The simple example would be a clock, say with a nice display. But clocks drift, so it would need a way to track the current time. That means it is connected to something like WWVB or GPS, and they both provide leap-pending announcements. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] stale leap second information
If you are only broadcasting the next or just recently occurred leap second, you can perhaps leave out the year and just give a month number, which is understood to be in a -2 .. +10 window around the current month. e.g. if I read a month number of 12 now I would understand that to mean there was a leap second at the end of last year, but if I read the same value in March I would understand there is a leap second at the end of this year. I don't think -2..10 is good enough. What if none is scheduled and the last one was a year ago? If nothing else, you need to reserve one code point for none scheduled. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] stale leap second information
The CRC is there to detect when DNS replies are rewritten to point everything at captive portals, as is the case on a lot of free WIFI networks etc. What do free WIFI portals do with TXT records? What do they do with NTP requests? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] stale leap second information
There is no problem if the message is Next leap second is #N at -MM
and after that changes to Next leapsecond is #{N+1} at unknown future
date.
I've seriously been contemplating offering such a service myself in order to
get reliable leap-second info in Ntimed...
Are you talking about clients or servers? Are the leap-bits in the current
NTP packet format good enough to get the info to clients if the servers are
setup correctly?
Do you also need the expiration date of the info?
Is DNS light weight enough that it's not worth the effort to avoid extra
lookups?
Can the DNS TTL be used for that? I'm not a DNS wizard, but I don't think
the data files feeding the current DNS servers are setup to process
valid-until-. A cron job could update the TTL each night.
--
These are my opinions. I hate spam.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] stale leap second information
If I understand the provenance, BIPM is responsible for maintaining atomic time and TAI, IERS is responsible maintaining for UT1 and Leap Seconds, and ITU is responsible for time dissemination. Whats not so clear, and it would be reassuring to know, is how the information is officially shared between these bodies and to what degree its automated. I don't think the ITU does any actual dissemination. They don't run any servers or radio transmitters. I picture the ITU as a level higher than that. They coordinate things like We all agree to use leap seconds and BIPM will figure out when they happen. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Do lawyers care (know) about leap seconds?
So you are saying that the UTC standard is so broken that you have to invent your own, which is not standardized by any standards body[*], to get around it? UTC is the required time base for business and has some odd quirks which mean that to comply with it you have to be an expert on the esoteric quirks of UTC, like the 61 second minute. Saying that it has to be sanitized before feeding it to the end user says implies that the standard isn?t really a standard and you have to ?fake it? by some weird means to keep user?s happy. How many contracts worry about seconds? I think it's common for contracts to start one minute before or after midnight to avoid an English language ambiguity. Things like midnight Monday might be the midnight at the start of Monday or the midnight at the end of Monday so contracts usually use 00:01 or 23:59. A bit of googling found a web page describing that, but I don't know what they teach in law schools. Do other languages have the same problem? How many languages have a simple and unambigious way to say midnight at the end of xxx? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
E) Leap seconds are tied to observations of the earth's spin, rather than predicted years in advance. With only 6 months warning for leap seconds, this produces operational difficulties for many environments that have burdensome change control policies. What do those organizations do when Congress changes the DST rules? Do they work on UTC/GMT so they can ignore DST? They must have to interact with the rest of the world occasionally. How much notice did people get the last time Congress changed the DST rules? I don't pay attention to summer time in Europe. How often do things change over there and/or how much notice do people get when the rules are changed? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Common Calendar Time (CCT) -Brooks Harris
Also, not all versions of POSIX are equally good. I've found smoking gun bugs in some implementations of gmtime() and related. Please put the details on a web page and tell us the URL. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Embedded software
The olson database updates will take care of that. One of the problems with leap-seconds is that they aren't predictable and the software in embedded gear doesn't get updated. That also means the time zone data doesn't get updated. What sort of embedded gear uses time but not time zones? Or are people willing to gamble that Congress won't mess with DST anytime soon? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Embedded software
All the embedded gear I've done runs on UTC. But it also has requirements for 'cold start' that are incompatible with GPS and couldn't be met if the system had been off across a leap second. It didn't deal with localtime, so DST insanity didn't matter so much... I can't quite figure out what that means. Where did it get leap-seconds info in the normal case? Was there a battery backed TOY/RTC? They typically have some (battery backed) RAM on the same chip. Could you have stored the leap info there? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Length of day :)
http://www.gocomics.com/pickles/2014/01/14 -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] When did computer timekeeping get good enough for leap seconds to matter?
The IBM 360 systems starting in 1964 used the power line frequency. (A location in low memory got bumped at 300 counts per second. 5 per cycle on 60 Hz and 6 per cycle on 50 Hz.) I wonder how much the power timekeeping wandered back then relative to today. Does anybody know what the guys in the power company control rooms do about leap seconds? Leap seconds started in 1972. I was at Xerox in the late 1970s. At boot time, Altos got the time from a local time server. Altos used the system crystal (5.88 MHz) for timekeeping. Personal Altos were rebooted frequently so it didn't matter if their clock drifted a bit. The time server was packaged with the routers. (We called them gateways.) On the few systems that were up a long time (file servers, routers), we hand tweaked a fudge factor to adjust the clock rate. It wasn't hard to get to a second per week. I think the units for the fudge factor (from a config file) were seconds per day, but it would read at least one digit past the decimal point. I don't remember any mention of leap seconds. When were there enough (Unix?) boxes on the net running NTP and keeping good enough time to notice things like leap seconds? I should go browse the old RFCs and see when the API for telling the kernel about pending leap seconds was published. But somebody may have good stories or folklore. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] When did computer timekeeping get good enough for leap seconds to matter?
p...@phk.freebsd.dk said: It used to be pretty good, because people used synchronous motors to drive clocks so the power companies tried to keep the long-term frequency correct. Microwave ovens still use the line for timekeeping. 1/2 :) I wonder how many old mechanical (synchronous) clocks are still ticking? I have two. One on a clock radio and one on my oven. In Denmark they usually lost a couple of seconds during the day and gained them back during the night, similarly they lost half a minute over winter and gained it back over summer. Do you have data or references for that? If I heard it from anybody less credible, I'd guess it was an urban legend? Was it accurate 50 years ago? The winter/summer variation doesn't make sense to me. If the PLL can cover daily changes, anything lower frequency would be covered for free. It's easy to collect data. Take an AC wall wart type transformer and connect it to a modem control pin that the kernel is setup to use for NTP's PPS signals. (Contact me off list if you want the software.) I have data from Silicon Valley and Zurich. I can't see any strong daily cycles. Some days are flat, some days it drifts one way, and some days it drifts the other. Mostly it wanders around. Typical peak-peak (SV) is 4 seconds per day. Here is a graph for the last 24 days: http://www.megapathdsl.net/~hmurray/time-nuts/60Hz/Dec-2013.png Midnight UTC is 4 PM local. Peak-to-peak over 24 days is 12 seconds. After deregulation nobody gets paid to keep the long term frequency, so mains is no good, actually down-right bad, for timekeeping anymore. At least in the US, the power companies are still required to keep good time. I don't know any details. There was a proposal a year or so ago to drop that. I gather it's a pain-in-the-ass type constraint on their overall operations. The proposal was dropped and I haven't heard anything since. Maybe somebody told them that microwave ovens have replaced synchronous motors. Maybe somebody figured out that it was cheaper to pay a few engineers to get things right rather than pay dozens of lawyers to get their proposal through Washington. This is getting off topic for leap-seconds, but maybe there are some details from the power industry that will shed some light on the leap-second issues. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Standards of time zones -Brooks Harris
(from a day or two ago...) Brooks Harris bro...@edlmax.com said: So I ask your opinion(s) - Do you think there's a need for a document like I've described? What standards body do you think would be receptive to the idea? Or is it a fool's errand? If I was going to try to fix that, I think I would start by talking to the OS and POSIX people. I don't know if they would be receptive. Even if they were, it might still be a dead end, but then I would (might?) learn something. The fundamental problem with POSIX timekeeping is that it pretends that leap seconds don't exist. What would you like for an API if you were starting over and wanted to support leap seconds? What would you have to change in the OS and libraries? There now exists lots and lots of software that uses the no-leap approach, and zillions of disks full of old/POSIX time stamps. We will never fix all of that, so we will be stuck supporting the old API forever. If the OS keeps time in TAI, then some combination of the OS and libraries needs to know when the leap seconds have and will happen. A common criticism of keeping time in TAI is that leap seconds are not predictable so it's hard to build embedded systems that will keep working in local time past the latest leap-second announcement. We should be able to tweak NTP to distribute a table of leap seconds. (Eventually, the table will overflow a UDP packet size. :) Are there any interesting systems where time is important but they don't have internet connections? How do they set their clocks? - In 2038, the 32 bit time-stamp wraps around into negative numbers. Maybe all 64 bit time stamps should be in TAI rather than UTC. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Longer horizon
(1) Push for a longer time horizon for leap second announcements. For compute guys, the more lead time the better. 6 months is just too short to meet deployment realities. 5 years would cover most bases, with 10 years covering all but a vanishingly small number. Even 2-3 years would help for two reasons. (1) it would mean only one upgrade during a 5 year deployment rather than possibly 10. (2) It would allow management to plan and budget for extra resources needed to ensure leapseconds will work this time. I don't understand this area. How often do systems need to get updated to track time zone changes? Maybe tracking leap second announcements every 6 months would help scheduling updates. Has the US Congress stopped playing with DST rules? When was the last change in Indiana? How often do things change in the EU or the rest of the world? Or are we talking about systems that don't use time zones? If so, what sorts of things do they do? How big is the problem space at the intersection of time matters but updating a table is hard? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Good description of Linux kernel bugs related to leap seconds
From Steven Bellovin, on NANOG: See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks .html I've been hoping somebody would post a good summary like that. It covers 5 different bugs. I'd split them into 3 clumps. The first clump is kernel deadlocks. As often happens with hard problems, fixing it here breaks it over there. That's the first 3 bugs. The 4th bug explains the CPU load spikes. A kernel bug broke futex-es. They are typically used in spin-lock like loops from user code. I don't understand the details. Setting the time (to any value) fixes the kernel problem so everything starts to work normally again. (No need to reboot.) The 5th bug is still a mystery. Also from NANOG: If folks have not read it, I would suggest reading Normal Accidents by Charles Perrow. I agree. This is a good excuse to find my copy and read it again. Yes, it's very good, but not directly related to leap seconds. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Indeed, but that is a different task from what I am trying to specify here. I'm only trying to do the API for dealing with present and past time and timeintervals past us, in a computationally efficient manner. There's a lot of business programming for which days are far more important than seconds, but in those cases (interest, book releases, etc), it's very much local legal time that matters, not a continuous timescale. Correct and current daylight saving time transitions are more important than leap seconds and milliseconds in those cases. I think the key idea is that there are several units of time and things like leap seconds, time zones, and leap years make conversion between them far from simple. We want to work with time in units of: SI seconds Days Years kilo- and mega- years Picking an API that focuses on one makes it hard to do things in the others. There are also months, but they are sufficiently non-uniform that nobody expects simple arithmetic conversions to work. If we are going to make any progress in this area, I think we have to come up a collection of APIs that cover all the needs and a good description of how to decide which one to use, and why. - It might be possible to use seconds to describe times in the future if you also carried along some sort of fuzziness range. The idea is to be able to say: X seconds from now, but I only need it to the day so I don't care about leap seconds or DST. (But that breaks when your country jumps across the international date line.) It might help if routines like localtime and gmtime had another parameter to tell them the round-off granularity: minute, hour, day, month, year, century... -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] ] Fractional US civil time period representation is brittle
Notice that I have not specified that the actual syscall must use FP, the conversion from 64.64 to FP could, and probably should, happen in libc. That means somebody could implement this now with current POSIX kernel support and see how well it works. -- My proposed API does not solve all imaginable problems relating to time, in particular it does not solve the programmer is clueless about time problem, but it does try to make it easier for programmers to do things right, than for them to make mistakes. I think it would be a big help if the documentation had a section describing the not-so-obvious parts of time. Are they all associated with leap seconds? How about leap years? (a year from today gets interesting) Perhaps it should go in a separate man page listed in the SEE ALSO pages of time commands. --- Has anybody made a list of routines that take time as a parameter? sleep, usleep, select... --- Testing for equality of timestamps? I would hope that using a FP format and mandate that for runtime you never get two which are the same, should eliminate that hobby. They might be equal if generated on two different systems. Even if we only have one system, I'm not sure I want a simple concept like get-the-current-time to require a lock on multicpu or multicore systems. -- You can create any UTC timestamp you want at any point in history where it is defined. But you can only convert that UTC timestamp to a realtime_t (and vice-versa) for timestamps where the conversion is defined. UTC is only defined approximately 6 months in advance, and that is an interesting point for implementors of this API. I think a useful system needs a way to say a year from now, or next Dec 25. -- One of the problems right now with the 'right' database is that you have to update it and already running programs don't notice this update since it would be prohibitively expensive to do a stat call on each time operation. Any clever ideas around this issue? 2 suggestions (we can debate the clever part): Poll once per day. Kick the program with a signal similar to what happens when log files get rotated, or piggyback on the same signal. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The ends we seek
We've given this some thought. One problem is that many of the contributors of the list have taken a side and have been re-defining words to enhance their bargaining positions. This makes a writing a wiki difficult. Would it work if we had 3 wikis? One for the good guys, one for the bad guys, and one for the technical details that (almost?) everybody agreed on? An alternative is to pick an editor that everybody trusts. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap seconds decision deferred until 2015
This works only when mars is an isolated world. If there were commerce between mars and earth, or other need to regularly communicate, then there would be demand for a uniform time scale for both, just like there was demand for a uniform time between cities that shared proximity 150 years ago. So all we have to do is procrastinate or muddle through until we develop serious commerce with Mars. Then we will have a bigger problem to sort out and we can toss Earth based leap seconds into the mess without any serious problems. I like it. 1/2 :) -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The ends we seek
[Leap years vs leap seconds] If UTC is discontinuous in any sense then so must the Gregorian calendar be, with a discontinuity 86400 times greater on Feb/29. Noone seems at all concerned about that discontinuity. There are two problems with leap seconds vs leap years. One is that leap seconds are harder to predict. The other is that leap seconds are much less significant. Leap years are a big deal. Everybody knows about them. You learn about them in grade school. They don't mention leap seconds at that level. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Time on time
Speaking of time, what sort of time is the Long Now clock keeping, anyway? Solar, atomic, or something else entirely? Solar. It's all mechanical. No electronics. From http://en.wikipedia.org/wiki/Clock_of_the_Long_Now Hillis concluded that no single source of timing could meet the requirements. As a compromise the clock will use an unreliable but accurate timer to adjust an inaccurate but reliable timer, creating a phase-locked loop. In the current design, a slow mechanical oscillator, based on a torsional pendulum, keeps time inaccurately, but reliably. At noon the light from the Sun, a timer that is accurate but (due to weather) unreliable, is concentrated on a segment of metal through a lens. The metal buckles and the buckling force resets the clock to noon. The combination can, in principle, provide both reliability and long-term accuracy. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] What timekeeping system should the Terra Nova settlers use
How would the people on this list who advocate for various treatments of future timekeeping in our own world deal with that situation? Fun question. Thanks. I'd setup two separate timekeeping systems. For measuring time (and frequency) in scientific experiments, I'd use some fixed unit and give it a new name to avoid confusion. I wouldn't tie it into dates, just use kilo and mega and giga for longer time spans. For solar time of day and calender dates, I think you either need rubber seconds or something like leap seconds. Are there any other options? If leap seconds happened more often the software would get debugged. If leap seconds were really rare, you could ignore them as long as the mechanisms for distributing UT1-UTC could handle the drift for some reasonable time span. Your great-great-...-grandchildren will have to sort it out, but that won't be a problem if they all escape to a new planet first. If you want to start over, I'd use 100 seconds per minute, 100 minutes per hour and 10 hours per day. (no AM/PM) Or something like that. --- What do the people at JPL do when they want solar time on Mars? I assume they have two clocks on the wall like some places have a second clock running on a different time zone. Humans naturally sync to Earth solar days. What happens if a day is half or twice as long? Years ago, I worked a 6 day week without any troubles, but I get tried if I try to stay up for 2 days. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Coding this week, and a trick for timeouts over leap seconds.
Try using clock() instead of gettimeofday_in_millisecs(). The former nicely increments with CLOCKS_PER_SEC resolution and is immune from UTC, timezones, and leap seconds. At least it does on windows. Can someone comment on unix/ linux? My Linux box has a man page that says: The clock() function returns an approximation of processor time used by the program. So I don't think that's interesting for wait-a-while. select, sleep, and usleep are the wait-a-while routines on POSIX systems. I don't know how they are actually implemented. I could easily imagine somebody turning them into wait until now+delta which might get confused by leap seconds. unsigned int sleep(unsigned int seconds); sleep() makes the calling process sleep until seconds seconds have elapsed or a signal arrives which is not ignored. int usleep(useconds_t usec); The usleep() function suspends execution of the calling process for (at least) usec microseconds. The sleep may be lengthened slightly by any system activity or by the time spent processing the call or by the granularity of system timers. int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); timeout is an upper bound on the amount of time elapsed before select() returns. If both fields of the timeval stucture are zero, then select() returns immediately. (This is useful for polling.) If timeout is NULL (no timeout), select() can block indefinitely. If I wanted to test/debug this sort of code, I would use the cycle-counter. Most modern chips have one. On i386 it's called TSC. It's not standard or portable, but you can hide it in a subroutine if you want to try to make the code somewhat clean. Should we setup a web page with a recipe to fake a leap second at midnight tonight? I think it would be something like: kill ntpd run a program to tell the kernel leap-tonight wait till midnight run a program to tell the kernel no-leap restart ntpd I think that needs a simple program to set the leap-tonight bits. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap smear
However, the tzdata approach ends up with no meaningful common sense definition. The offset becomes an ever increasing offset to some arbitrary clock to the length of day 500+ years ago that a bunch of time nerds back then was more important that the length of the solar day. I posit that people would be uncomfortable about that lack of ability to link the concept of time and offset to something meaningful, like a solar day. Time zones don't make sense until somebody explains that the Earth is a sphere and rotates about its axis and such. We don't have much troubles with them. It's only one more step to explain that the rotation rate is decaying and that the length of the second that they picked way back when doesn't quite match a normal day any more and that here is this neat graph of the differences... I'll bet third graders would pick it up. [I'm not saying we should drop leap seconds, just that I don't think that common sense is a good enough reason to not do it.] -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Consensus: Day vs Year (civil timekeeping)
Should the day be the basic unit for civil timekeeping? Why not year? Years cover things like when to plant crops which seems more important than when to get up in the morning. On the other hand, Gregorian rules may be good enough so we can use days as the basic unit if that's more convenient. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Robust vs brittle design
Getting further off-topic: http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande?printab le=true Great article! Thanks! If you like that article, I highly recommend his 3rd book: Checklist Manifesto. http://gawande.com/the-checklist-manifesto That article is (roughly) the first two chapters of the book. His first 2 books are good too, just less relevant to this discussion. [He is Atul Gawande.] -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Nit-pick: SI second
That may all be true. But is the SI second a unit of measurement? yes, one that can be reproduced a priori anywhere in the universe that someone has a cesium atom. Doesn't it depend upon gravity (aka sea level)? Is that standardized? -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] TAI adjustment ??
The process was even more complex while the rate of TAI was intentionally increased during 1995..1998. Could somebody say more? Or tell me what to google for? -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] [time-nuts] Merry 55555
For those of you with vintage Trak 6460 time scale generators (see http:// www.leapsecond.com/pages/trak6460) a special treat will occur at 13:20:00 UTC* on Christmas day. The time at the tone will be 5.5. Once in a lifetime. Neat find. Thanks for sharing. But you can get more. How many 5s do you want? 13:20 is 13*3600 + 20*60 = 48000 seconds 48000 / 86400 is 5/9 5/9 is 0.5... (repeating fraction) Does the Trak 6460 do the right with leap seconds? What is the right thing? -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] An example
Of course, since dates of the two calendars are generally indistinguishable, it's often not clear which version of the date is being reported. But historians are getting better at explicitly labelling the dates. So are archaeologists. The early carbon-14 work didn't understand about the influence of solar activity on C-14 production. I gather that recent papers referencing C-14 dates include a reference to which of several correction methods are available. (The corrections came from counting tree rings.) -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] ITU vs our forum
5) Every time we have one of these entertaining discussions, the one obvious fact is that nobody associated with pushing the issue through the ITU-R is choosing to participate in our forum. Is anybody surprised? The ITU is an official body, sanctioned by the UN and indirectly by most national governments through treaties. They get to make the rules. Why should they pay attention to us? Is there anything we can do about it? Is there even consensus within this group? I would readily agree that I haven't seen a document that looks like a good overview, discussing the problem and the costs/benefits of various options. (There might be one, or something like it, hidden within ITU. It's also possible the info is there but spread across various emails or the minutes of many meetings.) I'd also agree that we/they shouldn't do anything without a document like that and time to review it and ... I can live with leap seconds, but it wouldn't be hard to convince me to turn them off and let DUT1 grow. But my vote/opinion probably doesn't matter. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Cost: getting rid of GMT discontinuing leap seconds
Medicine production is another case: In continuous production setups, all materials have to be traceable to with second granualirity (FDA, EU and other regulations), which basically means that either nothing happens over the leap second (ie: maintenance shutdown) or everything in the factory has to cope correctly with leap seconds. Does anybody care about the seconds? Does anybody ever check to verify that the clocks are correct? It might be handy as a unique-ID. (Similar to the way that silicon chips use the year+week as a batch marker.) Another place where seconds are important is the stock market. I don't know the details. Obviously it doesn't matter what time scale they use as long as everybody uses the same one. (and the legal paperwork says it's OK) Most major stock exchanges are closed for New Years Day. I expect there are some computerized systems that run 365x24. It might get interesting if a leap second happened in June. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Coming of age in the solar system
As for the handling of leap seconds in practice, it's whatever the local NTP says it is. Most seem to repeat the last second. Actually, I think it's whatever the kernel does. NTP just tells the kernel to leap at midnight (and which direction). -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
