similar to: New leap second end of 2016 / beginning 2017 (depending on TZ)

sorry, i didnt watch src/main/datetime.c ... Index: leap_second/src/main/datetime.c =================================================================== --- leap_second/src/main/datetime.c (????? 68608) +++ leap_second/src/main/datetime.c (?????) @@ -303,14 +303,15 @@ } #ifndef HAVE_POSIX_LEAPSECONDS -/* There have been 25 leapseconds: see .leap.seconds in R +/* There have been many

hi, Index: leap_second/src/library/base/R/zdatetime.R =================================================================== --- leap_second/src/library/base/R/zdatetime.R (revision 68608) +++ leap_second/src/library/base/R/zdatetime.R (working copy) @@ -24,7 +24,8 @@ "1979-12-31", "1981-6-30", "1982-6-30", "1983-6-30",

Thanks, I was working on this. There are other changes needed in src/main/datetime.c and ?.leap.seconds which I will commit shortly, and the example in hist.POSIXt() needed alteration (it seems DJM did not run 'make check'!). On 01/07/2015 06:20, Ei-ji Nakama wrote: > hi, > > Index: leap_second/src/library/base/R/zdatetime.R >

On Tue, Jan 20, 2015 at 3:27 PM, Michael Hennebry <hennebry at web.cs.ndsu.nodak.edu> wrote: > Unix and ntp handle leap seconds a bit differently. > Unix time increases during the leap second and drops back a second after. > Ntp freezes time during the leap second. > OS kernels may do either or neither. Does anyone have a succinct summary of how to prove to management-types that

On the documentation page for DateTimeClasses, in the Examples section, there are the following two lines: format(.leap.seconds) # the leap seconds in your time zone print(.leap.seconds, tz = "PST8PDT") # and in Seattle's The second line (using print) seems to ignore the tz argument, and prints the dates in my time zone, while: format(.leap.seconds, tz =

At 2012-06-30, leap second will be introduced. ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat Does Samba affect leap second? -- --- Oota Toshiya --- t-oota at dh.jp.nec.com NEC Systems Software Operations Unit Shiba,Minato,Tokyo IT Platform Solutions Division Japan,Earth,Solar system (samba-jp/ldap-jp Staff,mutt-j/samba-jp postmaster)

On Thu, Jan 15, 2015 at 9:04 AM, Akemi Yagi <amyagi at gmail.com> wrote: > On Thu, Jan 15, 2015 at 8:43 AM, G Galitz <geoff at galitz.org> wrote: >> We have another leap second coming. Have past bugs with Centos and leap >> seconds (specifically high CPU spikes) been resolved? Should we be worried? > > Apparently Red Hat is well aware of the upcoming leap second:

Hi. We have another leap second coming. Have past bugs with Centos and leap seconds (specifically high CPU spikes) been resolved? Should we be worried? -G

On Fri, Mar 6, 2015 at 2:04 PM, Gordon Messmer <gordon.messmer at gmail.com> wrote: > On 03/06/2015 01:41 PM, Les Mikesell wrote: >> >> I just want the package revisions for at least the kernel and tzdata* >> files and anything else where previously-found bugs related to the >> leap second have been fixed. > > > https://access.redhat.com/articles/15145 In

On Fri, Mar 6, 2015 at 1:50 PM, <m.roth at 5-cent.us> wrote: >> >> I don't think I need to 'prove' that computer programs do repeatable >> things. I just want to know the version numbers that need to be >> installed - something relatively easy to check. > <snip> > Two other thoughts: first, that it worked perfectly fine the last leap >

On Fri, Mar 6, 2015 at 4:04 PM, Gordon Messmer <gordon.messmer at gmail.com> wrote: > On 03/06/2015 01:41 PM, Les Mikesell wrote: >> >> I just want the package revisions for at least the kernel and tzdata* >> files and anything else where previously-found bugs related to the >> leap second have been fixed. > > > https://access.redhat.com/articles/15145

On Thu, Jan 15, 2015 at 3:00 PM, Rob Kampen <rkampen at reaching-clients.com> wrote: > > Fascinating - describes what's happening but no mention of how we can rest > assured that all will be well.... > As I ponder it, I recognise that most of our systems are constantly > calculating date/time values based upon the epoch - the number of seconds > since a particular

On Fri, Mar 6, 2015 at 12:52 PM, Chris Adams <linux at cmadams.net> wrote: > Once upon a time, Les Mikesell <lesmikesell at gmail.com> said: >> Does anyone have a succinct summary of how to prove to >> management-types that a given linux box won't have a problem with the >> leap second? Like kernel > some_version, tzdata > some_version, >>

--------------------- Kernel Begin ------------------------ 1 Time(s): Clock: inserting leap second 23:59:60 UTC ---------------------- Kernel End ------------------------- hee hee. gotta love it....

> -----Original Message----- > From: Akemi Yagi > Sent: Thursday, January 15, 2015 12:05 > > On Thu, Jan 15, 2015 at 8:43 AM, G Galitz <geoff at galitz.org> wrote: > > > > Hi. > > > > We have another leap second coming. Have past bugs with > Centos and leap > > seconds (specifically high CPU spikes) been resolved? > Should we be worried?

On Fri, Mar 6, 2015 at 3:15 PM, Chris Adams <linux at cmadams.net> wrote: > > Short answer: last time it was threaded stuff like Java, the time before > it was systems under heavy kernel loads. Who knows, this time Postfix > could hang, or MySQL could corrupt databases, or something else. > Probably nothing will happen, but if you want a "cover your ass" report,

I glanced at the .leap.seconds object and noticed that it has not been updated for the most recent leap second that occurred 2005 December 31, 23h 59m 60s. See the IERS bulletin here: http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat Moreover, after a more careful glance at the .leap.seconds object, I noticed that there are two incorrect entries. First, there was not a leap second on 1986 June

Once upon a time, Les Mikesell <lesmikesell at gmail.com> said: > Does anyone have a succinct summary of how to prove to > management-types that a given linux box won't have a problem with the > leap second? Like kernel > some_version, tzdata > some_version, > tzdata-java > some_version? Only way to "prove" it is to set up a test and try it. AFAIK there

openSUSE Leap 15 has "opensuse-leap" as ID in os-release, so add it both in the detection code of the RPM handler, and in test-harder.sh. --- src/ph_rpm.ml | 2 +- tests/test-harder.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/ph_rpm.ml b/src/ph_rpm.ml index b0a5eb2..3caa38e 100644 --- a/src/ph_rpm.ml +++ b/src/ph_rpm.ml @@ -40,7 +40,7 @@ let

>>>>> Jennifer Lyon <jennifer.s.lyon at gmail.com> >>>>> on Thu, 15 Dec 2016 09:33:30 -0700 writes: > On the documentation page for DateTimeClasses, in the Examples section, > there are the following two lines: > > format(.leap.seconds) # the leap seconds in your time zone > print(.leap.seconds, tz = "PST8PDT") # and in