How is everyone going to handle a leap second added to the end of 2016, for kube-aws created clusters? about kube-aws

[pieterlange]

I think this is more of an issue for CoreOS upstream.

[mumoshu]

Could be. I wish CoreOS had a guide like RedHat does.

[mumoshu]

You can blame be for doing this but cross posted to the coreos users' group! https://groups.google.com/forum/?hl=ja#!topic/coreos-user/tMaJtso7Ky4

[mumoshu]

Closing this as probably no one is interested 😢

[mumoshu]

Note to self: It turns out we can just source from a leap-smearing NTP server instead of the default one so that a leap is handled on their side.

[aholbreich]

@mumoshu you can source time from google or whatever but that does not prevent your system to include .60 second automatically or? I would not expect that without special treatment

[mumoshu]

@aholbreich Thanks for catching this up 👍
AFAIK, Google Public NTP serves leap-smeared time hence sourcing it ends up making a leap second invisible from our ntp clients and hence our clock.

[aholbreich]

Nice info @mumoshu, found this too now: http://www.theregister.co.uk/2016/12/02/google_public_ntp_servers/

I was thinking if it still has any troubles with tzdata (time zone database) that includes leapseconds. But maybe in case of smearing it has no effect.