From Michael.Paoli at cal.berkeley.edu Sat Dec 3 10:33:55 2016 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Sat, 03 Dec 2016 10:33:55 -0800 Subject: [buug] Leap second cometh: 2016-12-31T23:59:60+0000 2016-12-31T15:59:60-0800 Message-ID: <20161203103355.149159k22qqz2r0o@webmail.rawbw.com> Leap second cometh. Ooooh, and smears and not. Now we can have many millions or more clocks disagree about what time it is for up to 24 hours. 2016-12-31T23:59:57+0000 2016-12-31T15:59:57-0800 2016-12-31T23:59:58+0000 2016-12-31T15:59:58-0800 2016-12-31T23:59:59+0000 2016-12-31T15:59:59-0800 2016-12-31T23:59:60+0000 2016-12-31T15:59:60-0800 2017-01-01T00:00:00+0000 2016-12-31T16:00:00-0800 2017-01-01T00:00:01+0000 2016-12-31T16:00:01-0800 2017-01-01T00:00:02+0000 2016-12-31T16:00:02-0800 2017-01-01T00:00:03+0000 2016-12-31T16:00:03-0800 https://developers.google.com/time/smear#othersmears http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14. $ fgrep leap /etc/ntp.conf leapfile /usr/share/zoneinfo/leap-seconds.list $ fgrep Jan\ 2017 /usr/share/zoneinfo/leap-seconds.list 3692217600 37 # 1 Jan 2017 $ My gosh, some might be off up to a second on the start of their New Year's celebration. Ah well, at least we'll get our clocks better aligned to solar time again. And we don't have the nasty mess of the past, where the time period for the length of the second changed, by definition. At least the sun dials aren't too far off. https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Unix_time#Leap_seconds https://en.wikipedia.org/wiki/Network_Time_Protocol https://en.wikipedia.org/wiki/Network_Time_Protocol#Leap_seconds ntpd(1) (notably also -x option) From itz at primate.net Sat Dec 3 16:30:25 2016 From: itz at primate.net (Ian Zimmerman) Date: Sat, 3 Dec 2016 16:30:25 -0800 Subject: [buug] Leap second cometh: 2016-12-31T23:59:60+0000 2016-12-31T15:59:60-0800 In-Reply-To: <20161203103355.149159k22qqz2r0o@webmail.rawbw.com> References: <20161203103355.149159k22qqz2r0o@webmail.rawbw.com> Message-ID: <20161204002926.6473.0C74F4E8@matica.foolinux.mooo.com> On 2016-12-03 10:33, Michael Paoli wrote: > Leap second cometh. So, is there anything I need to do to defend myself, on a reasonably well behaved distribution? -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html From hauke.laging at linux-presentation-day.org Sun Dec 11 14:34:24 2016 From: hauke.laging at linux-presentation-day.org (Hauke Laging) Date: Sun, 11 Dec 2016 23:34:24 +0100 Subject: [buug] expanding Europe's Linux Presentation Day to the US Message-ID: <3027149.Ad9DYCHe2k@inno> Hello, in May 2015 Berlin's Linux user group (BeLUG) has started a new type of event which has spread quickly all over Europe and recently (for the next event) to other parts of the world, too: the Linux Presentation Day (LPD) 2015.1: Berlin only 2016.1 & 2016.2: 120+ cities in 15 European countries 2017.1: first locations outside Europe (USA, Canada, New Zealand, probably Australia and Israel, too; April / May 2017) Until now there were large LPD events in Germany and Italy only. In most countries there are only a few locations. But the first LPD in the USA will probably be a large event, too. I contact you because you are probably interested in a larger propagation of Linux. The aim of the LPD towards the general public is to provide biannual and comprehensive information events about Linux for private users who would like to get a first impression of Linux. The aim towards the media is to make the event so big (both nationally and internationally) that the nationwide non-IT media cover it (and thereby Linux) regularly. The aim towards the Linux community is that an LPD event can be very small and easy to organize (even without costs). The local organizers decide on their own what their event shall be like; we just make suggestions and offer support (e.g. free posters and stickers). You can find a longer description of the concept here: http://www.linux-presentation-day.org/idea/ Are you as an organization interested in participating in the LPD? If not: Are any of your members interested in helping us bring the LPD to the US? This event is very useful for finding new members. Best regards, (Mr.) Hauke Laging -- http://www.linux-presentation-day.org/ International phone contact for the Linux Presentation Day: tel:+49-30-55579620 (13:00–23:00, German and English) XMPP (Chat with OTR): linux-presentation-day at jabber.ccc.de OTR: 91626899 1C06F2BD 75EC2441 35C696CE 38F75997 From Michael.Paoli at cal.berkeley.edu Tue Dec 20 08:27:42 2016 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Tue, 20 Dec 2016 08:27:42 -0800 Subject: [buug] BALUG: no BALUG meeting in December, next BALUG meeting: 2017-01-17 Message-ID: <20161220082742.20277e4uodj696o0@webmail.rawbw.com> BALUG: no BALUG meeting in December, next BALUG meeting: 2017-01-17 Just a reminder, BALUG typically doesn't meet in December - we have no BALUG meeting this month. Next BALUG meeting: 2017-01-17 If you want to start marking your calendars for upcoming BALUG meetings: 2017-01-17 2017-02-21 2017-03-21 2017-04-18 2017-05-16 2017-06-20 2017-07-18 2017-08-15 2017-09-19 2017-10-17 2017-11-21 http://www.balug.org/#Meetings-upcoming From Michael.Paoli at cal.berkeley.edu Sat Dec 31 23:25:35 2016 From: Michael.Paoli at cal.berkeley.edu (Michael Paoli) Date: Sat, 31 Dec 2016 23:25:35 -0800 Subject: [buug] anything I need to do: Re: Leap second cometh: 2016-12-31T23:59:60+0000 2016-12-31T15:59:60-0800 In-Reply-To: <20161204002926.6473.0C74F4E8@matica.foolinux.mooo.com> References: <20161203103355.149159k22qqz2r0o@webmail.rawbw.com> <20161204002926.6473.0C74F4E8@matica.foolinux.mooo.com> Message-ID: <20161231232535.161738igup1v88ao@webmail.rawbw.com> > From: "Ian Zimmerman" > Subject: Re: [buug] Leap second cometh: 2016-12-31T23:59:60+0000 > 2016-12-31T15:59:60-0800 > Date: Sat, 3 Dec 2016 16:30:25 -0800 > On 2016-12-03 10:33, Michael Paoli wrote: > >> Leap second cometh. > > So, is there anything I need to do to defend myself, on a reasonably > well behaved distribution? Well, for now, that time is again past (the leap second happened at midnight ... UTC / GMT0). But reset assured, it will come again. For Unix/Linux, if you've got a reasonably well behaved operating system / distribution, and you're reasonably current on updates/patches, and your applications are well behaved, and if you and your applications aren't concerned about quite accurate/synchronized time more accurate than within about one second, then you probably have nothing to worry about. If some of that doesn't apply, or you're otherwise interested/curious, read on. Leap second - once upon a time, the second was 1/(24*60*60) of a solar/astronomical day (or at least a well averaged one). That, however, was a problem, as the second was - and is, fundamental unit of time measurement and, well, days just aren't that uniform. As it became possible to much better and accurately measure time, the second was redefined ... atomic clocks 'n all that. That left an itty bitty problem - getting civil time to stay reasonably in sync with solar/astronomical time. So, to solve that: leap second. https://en.wikipedia.org/wiki/Leap_second (Which is much better than the old situation - where the length of the second was varied ... egad! - yeah, that'd surely screw up your highly accurate physics timing experiments ... not to mention constant speed of light in vacuum, etc. - so yes, the second needed to be fixed to be a fixed and accurate interval of time.) But then there's computers, and Unix and Linux. Per POSIX, for the most part, Unix/Linux sort'a kind'a ignores leap seconds: https://en.wikipedia.org/wiki/Unix_time System time in Unix/Linux is seconds since the Unix epoch - *not including leap seconds*. Ah, but can't ignore them entirely - they have to be dealt with *somehow*. So - *somehow* - that extra leap second has to be "inserted"* to make POSIX and all else with Unix/Linux happy. *theoretically a leap second can be negative - the *removal* of a second - but thus far that's never occurred, and is unlikely to occur. So ... what happens on Unix/Linux, with leap seconds, and how is that all dealt with? Well, it depends. First of all, if you've got old unpatched stuff, it may be dealt with very poorly - notably some leap second related bugs can cause crashes/hangs or the like. And even if you're running old crufty software, there are work-arounds ... at least for potential leap second issue(s). And even if you have quite current patched stuff, that doesn't fully guarantee one has zero bugs related to leap second - in which case work-arounds can be useful - but there are tradeoffs. So, dealing with leap seconds. Various approaches. First of all, how many seconds per minute and what's returned by the various library calls and such? There are up to 61 seconds per minute, so, the seconds after the minute can be in the range [0..60] - not just [0..59]. If the software can't handle that 61th second, e.g.: 23:59:60 - then it's broken/buggy ... but again, there are work-arounds. Likewise for software/libraries that convert time specifications, including seconds after the minute, etc. - to system time - they need to also handle a time specification given with leap second data (however, results of putting in that extra second, or portion thereof, for any minute that doesn't include a leap second or could not even possibly be a leap second, may be unspecified - but even in such cases, software ought do something reasonable). So ... what's Unix/Linux do about leap second? In the "bad old days" ;-) - totally ignore it - one would just need to set/adjust the system time if/when it was off. At first one could merely set it to some specific time - nothing else was available "way back then" - as superuser ("root") - one could use the date(1) command to set the time - the time was specified, it was converted to seconds past the Unix epoch, and the clock was set to that (using stime(2)), and that's all there was to it - no more, no less. Then capabilities were added to slew the clock - one could speed it up or slow it down - so if it was off, it could be adjusted in a manner generally much less disruptively - but there still wasn't a way to directly add a leap second - one was still limited to setting the clock, and/or slewing it. Then along came ways to sync system time to some other time source, e.g. some reference time. Nice - no more manually mucking about with clocks, right? Hassle and thought free? Uhm, ... almost, but not quite. Even well set up and synced with NTP - there are those leap seconds to deal with. So - how is that done, and what does Unix - or your Linux distribution do, and do by default? Well, defaults vary - and even behavior of various NTP source clocks vary! And again, there are tradeoffs. Some of the various methods from old (ancient) school, and most/more risk adverse, to newest-fangled most accurate: (Mostly) ignore it, bury head (/system clock) in sand and pretend it doesn't exist: Shut systems down well before leap second. Start them up again well after. Clock can be jumped to correct time at restart, or (if available) slewed to correct time. Leave systems running, but have them (mostly) oblivious to leap second: disable/remove/clobber anything that'd make the system think a leap second would occur. Don't have data/flags present or set to tell the system there's a leap second: For any time sync, either: disable it well enough in advance, and reenable after (clocks can then either jump, or slew, to the correct time, depending upon the actions taken and/or how configured), or have it "smear" time - using time source (e.g. "smear"ed NTP), that adds the extra second by slowing the clock - but only by a little bit, over a fair stretch of time (typically over 1000s to 24h), so it generally doesn't cause other issues. This has advantage of keeping clocks in sync - at least within, e.g. an organization or organizations, where all are using the same smear, and while avoiding hazards of more accurately processing a leap second - but has the disadvantage that those clocks will be up to about one second (or at least 1/2 of a second) off through that smear transition. NTP & slew (ntpd -x) still gradual, but generally much faster than most of the "smear"s noted above, clocks stay accurate and synced up to the leap second, after that clocks slew towards correct time at ntpd+kernel maximum slew rate, which is generally "slew rate of typical Unix kernels is limited to 0.5 ms/s" (ntpd(8)) - so that takes approximately 2,000 seconds for the clocks to get back to the correct time. "jump" - kernel leap second time discipline. If using ntpd without -x option, and with accurate ntpd source clock and one that passes along leap second information (there's a flag in the NTP protocol), or with ntpd given leap second information (ntp.conf(5) leapfile), or by other software that does similarly, and with capable kernel (e.g. non-ancient linux), a leap discipline flag is set and passed along to the kernel. That tells the kernel we have a leap second coming up, and when it occurs, to effectively "insert" the leap second. Now, since with POSIX and system time, as far as POSIX is concerned, the leap second doesn't exist. What this does with Linux and other Unix and BSD, etc. kernels, may perhaps be implementation dependent (maybe if I get a bit of time, I'll test/investigate a bit more closely). ... This is where I may not fully know the implementation details (please feel free to add/correct - may also vary depending upon various kernels - Linux and/or others). Essentially, kernel with flag set, will have correct time up to one second before leap second, and again after leap second. And ... the two seconds of time from 23:59:59 ... 23:59:60 ... 00:00:00 - where two seconds of real time elapse, but the POSIX second (Unix time - seconds since epoch) only goes up by one second? I've read different things, but sounds like that second of system time - two seconds of real time - the system clock runs at half speed, or it might effectively "repeat" that POSIX second (the second part wouldn't change, but would last two real time seconds, however the fractional portion of time past the second would repeat), or it could run at realtime/speed, up until right near the end of that second - then run super slow at the tail end of that second - enough to effectively insert the leap second, and then resume running at realtime rate thereafter - being again in correct sync to realtime at the very end of the leap second. Whichever approach - or any - is imperfect, but these are among the "most accurate" - time is kept fully accurately, except for a slight bit of funkiness for at most, two seconds of real time. Also, much software, and many things on Unix/Linux etc., often don't do well if the actual system time goes *backwards* - so, if the second is repeated, that can be problematic for some things - but since the POSIX second itself doesn't go back, that part isn't repeated - no jump in time there - but factional second portion could repeat if the second, effectively as a whole is repeated. And also, if that system time just goes twice as slow, taking two seconds of real time for one second of system time, for those two real seconds (or alternatively going real slow at the end), anything quite sensitive to the rate of system time passing could have issues (think of your real-time kernel accurately syncing the rotational speed of a massive industrial metal disk that's to be kept rotating at precisely 6,000 RPM ... "oops" - what if you're a power generating company and you have to keep your multi-Megawatt hydroelectric generator running at quite precise constant speed to stay synced to a grid at precisely 60 Hz so not only can power be transferred (by slight adjustments to phase/amplitude) - but you have the responsibility of accurate time - and keeping the entire country's motor driven AC synchronous clocks properly in sync - any sync changes and you alter thousands or millions or more clocks around the country or more and mess up folks time standards and may cause equipment/timing malfunctions, etc. I even have an older digital alarm clock radio that keeps its time by counting the AC power line cycles - I presume PG&E maintained 60 Hz, and that clock "lost" one second (it has no way to insert the second ... other than me setting the clock ... or unplugging it briefly - so it misses those AC cycles - but the DC capacitors don't lose so much charge that the clock drops time state ... and yes, that clock - can do that to slow it up to a maximum of about 10 seconds that way ... so, yes, I can "insert" a leap second for it by unplugging its AC power for precisely one second). So ... if your system and software is reasonably patched/updated, or you're using relevant work-arounds, and you're not concerned about time being incorrect or out-of-sync by up to about a second, and your software can handle the 61st second with the minute (or you've done the work-arounds so your system won't experience that), and you can deal with two seconds of real time taking a second of system clock time and possibly the fractional portion of second repeating (or you've applied work-arounds so you don't see that), and you don't have an issue with these discrepancies of clocks and real-world time of up to about a second, well, then you've pretty much nothing to worry about regarding leap seconds. But if you've got bad/old/broken/buggy software, and haven't at least applied work-arounds, then you might experience issues. Even if you have nice current well patched software, there's small probability one might have issues if work-arounds aren't applied, but that probability is low - and work-arounds trade off accuracy for stability and predictability. For Unix, Linux, etc., unless/until POSIX comes up with a "better" solution, we'll continue to have these less than 100% fully ideal leap second "solutions". Note the fundamental problem with POSIX seconds since Unix epoch and civil time - for any number of seconds since the epoch, have to be able to convert that to/from civil time - including times in past (at least since epoch), and times in future (at least to the end of Unix time). The issue with that is we don't know well in advance what leap seconds we'll have. So for that reason, POSIX mostly pretends that leap seconds don't exit. Oh, and fun with timezones ... the right/ timezones include leap seconds, whereas the others don't - yeah, I haven't looked into exactly how those timezones reconcile with POSIX ... or if they do. Oh, and there are some alternatives that have been proposed. Most notably, totally doing away with leap seconds ... but that then breaks everybody's sun dials and solar and astronomical time (as it is, with leap seconds, civil time is kept within 0.7s of solar/astronomical time). Just my humble opinion, but I think it's better that we have leap seconds than not. I think we just need better evolve our software and systems to deal with them. Perhaps there will be some extensions to POSIX at some point, to allow for better handling of this. We're *almost* there - really just need better ways to deal with leap second itself - all else with POSIX and time is already pretty well addressed. Happy New Year! Did y'all put your extra second to good use? ;-) http://buug.org/pipermail/buug/2016-December/004165.html adjtimex(2) adjtime(3) stime(2) date(1) clock(3) ctime(3) difftime(3) gettimeofday(2) gmtime(3) localtime(3) mktime(3) strftime(3) strptime(3) time(2) time(7) timegm(3) tzset(3) utime(2)