Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News
On May 21, 2015, at 7:49 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 20150521134322.gg10...@ucolick.org, Steve Allen writes: POSIX does not want to know geophysics, nor astrometry, nor politics. POSIX does not care what is meant by day. POSIX wants someone else to decide what day means, and for all those other details to be handled outside the kernel in the libraries and applications. POSIX is not just a kernel API, it *also* defines the functions for deciding what day means and all that. POSIX has decided that a day is 86400 seconds. Thus you can’t implement days with leap seconds with SI seconds. And you can’t have a system that’s synchronized to UTC if you smear seconds or ‘drop’ that second. The down stream effects are a bunch of bad choices, which bad choice you make depends heavily on the application. Some (maybe most) second smearing is good. Others, where stable elapsed time matters a lot, smeared seconds are a disaster, but dropping a second is also bad. Having multiple choices here leads to poor quality of implementation of leap seconds. To do things moderately close to ‘right’ you have to invent your own thing, and then translate your ‘right’ thing into the imperfect POSIX thing and accept those folks that use purely POSIX interfaces can never have the whole story and will have some aspect of their time keeping disrupted around leap second events. The real problem here is that POSIX defines time passing in such an abstract way that you can’t use UTC to realize it without something giving. Warner signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
On 19/05/15 08:30 PM, Joseph M Gwinn wrote: From: Eric R. Smith ersm...@hfx.eastlink.ca To: Leap Second Discussion List leapsecs@leapsecond.com True UTC (with leap seconds) didn't cure a problem the committee cared about, and managed to cause problems they did care about. In short, POSIX systems have to be able to work in a cave, with no access to the sky or knowledge of astronomy. If POSIX time_t were actually a count of SI seconds elapsed since the epoch, then a machine in a cave (with an accurate enough clock) could in principle maintain correct timestamps. As it stands though, POSIX time_t cannot be implemented without access to a UTC reference of some kind, i.e. access to the sky. Well, while POSIX mentions SI seconds, the standard is careful to say that these seconds are not exactly SI seconds (because UNIX workstations can have pretty bad clocks). And the standard specifically disclaims being UTC, despite the appearance. Read the standard carefully. It is intended and designed to support isolated operation. I don't have the actual standard in front of me, but have seen claims that POSIX time_t is defined (for years after 1970) to be: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 and that each and every day shall be accounted for by exactly 86400 seconds. Is this correct? Since the length of the day is not in fact exactly 86400 SI seconds, it would follow that a POSIX compliant system has to know how many days have elapsed since the epoch, i.e. it needs to have some kind of access to the sky. Am I misunderstanding something? Regards, Eric ___ 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
LEAPSECS leapsecs-boun...@leapsecond.com wrote on 05/21/2015 08:02:09 AM: From: Eric R. Smith ersm...@hfx.eastlink.ca To: Leap Second Discussion List leapsecs@leapsecond.com Date: 05/21/2015 08:01 AM Subject: Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News Sent by: LEAPSECS leapsecs-boun...@leapsecond.com On 19/05/15 08:30 PM, Joseph M Gwinn wrote: From: Eric R. Smith ersm...@hfx.eastlink.ca To: Leap Second Discussion List leapsecs@leapsecond.com True UTC (with leap seconds) didn't cure a problem the committee cared about, and managed to cause problems they did care about. In short, POSIX systems have to be able to work in a cave, with no access to the sky or knowledge of astronomy. If POSIX time_t were actually a count of SI seconds elapsed since the epoch, then a machine in a cave (with an accurate enough clock) could in principle maintain correct timestamps. As it stands though, POSIX time_t cannot be implemented without access to a UTC reference of some kind, i.e. access to the sky. Well, while POSIX mentions SI seconds, the standard is careful to say that these seconds are not exactly SI seconds (because UNIX workstations can have pretty bad clocks). And the standard specifically disclaims being UTC, despite the appearance. Read the standard carefully. It is intended and designed to support isolated operation. I don't have the actual standard in front of me, but have seen claims that POSIX time_t is defined (for years after 1970) to be: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 and that each and every day shall be accounted for by exactly 86400 seconds. Is this correct? Since the length of the day is not in fact exactly 86400 SI seconds, it would follow that a POSIX compliant system has to know how many days have elapsed since the epoch, i.e. it needs to have some kind of access to the sky. Am I misunderstanding something? Yes. The actual standard. HTML access is free. https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=11701 Look for Seconds Since the Epoch et al in the Rationale volume. The disclaim of UTC is explicit. There was a long thread on this on Time Nuts, where I published the details and links to the actual standard. Joe Gwinn ___ 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
On Thu 2015-05-21T09:02:09 -0300, Eric R. Smith hath writ: and that each and every day shall be accounted for by exactly 86400 seconds. Is this correct? Since the length of the day is not in fact exactly 86400 SI seconds, it would follow that a POSIX compliant system has to know how many days have elapsed since the epoch, i.e. it needs to have some kind of access to the sky. Am I misunderstanding something? POSIX does not want to know geophysics, nor astrometry, nor politics. POSIX does not care what is meant by day. POSIX wants someone else to decide what day means, and for all those other details to be handled outside the kernel in the libraries and applications. If that decision for the kind of day is any form of Universal Time then, over the long span of time, POSIX is counting mean solar seconds, not SI seconds. -- Steve Allen s...@ucolick.org WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m ___ 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
Eric R. Smith ersm...@hfx.eastlink.ca wrote: it would follow that a POSIX compliant system has to know how many days have elapsed since the epoch, i.e. it needs to have some kind of access to the sky. Only to the extent that its owners want it to know the correct time. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Tyne, Dogger, Fisher: West or southwest 4 or 5, occasionally 6 later. Slight or moderate. Occasional rain. Moderate or good. ___ 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
In message 20150521134322.gg10...@ucolick.org, Steve Allen writes: POSIX does not want to know geophysics, nor astrometry, nor politics. POSIX does not care what is meant by day. POSIX wants someone else to decide what day means, and for all those other details to be handled outside the kernel in the libraries and applications. POSIX is not just a kernel API, it *also* defines the functions for deciding what day means and all that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
I stand by my original statement. The label on the box is a mass specification, not a force specification. See the reference provided. If you want to pick at the statement you would have to resort to relativity, in which case I would correct to rest mass. Sent from my iPad On May 20, 2015, at 1:51 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 32c69001-db69-46c4-905f-d994b017b...@tcs.wap.org, Jonathan E. Hardis writes: That box of Wheaties that is labelled 'Net Weight 10 oz' would correctly weigh 10 oz everywhere on Earth, on the Moon, and on the ISS. It does not. For several reasons, but mainly because the enclosed air changes means that the bouyancy depends on air-pressure and thus altitude. That goes for anything which isn't enclosed by a rigid container with neglible elasticity in the range of relevant air-pressures. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
On Wed, May 20, 2015 at 3:02 AM, Richard Clark rcl...@noao.edu wrote: One of its examples of how the metric system is bad was its confusing use of two units, the newton and the kilogram, to measure weight. The US system is so much simpler and sensible with just one unit, the pound. I am not sure of what os common in the general US population, but engineers I have worked with outside the US used slug vs pound to differentiate mass vs weight (force). I also heard one US engineer use pound vs poundal (the pound being mass, the poundal weight), which he claimed was easier to use (scaling factors, got rid of the pesky 32.xxx). -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane ___ 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
In message 05704fac-8087-42ca-bb03-51c4b21c6...@tcs.wap.org, Jonathan E. Har dis writes: I stand by my original statement. The label on the box is a mass specificati= on, not a force specification. See the reference provided. I didn't say the label didn't describe a mass, I said that your blanket statement: That box of Wheaties that is labelled 'Net Weight 10 oz' would correctly weigh 10 oz everywhere on Earth, on the Moon, and on the ISS. ...is not correct, because the mass is only applicable in the local environment at the shipping factory. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
In message dce2e991-a54d-42af-98f8-2d5087fbf...@leapsecond.com, Tom Van Baak writes: https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ So already here the trouble starts: Google uses a smooth curve for their clock-smearing and Amazon uses a piecewise linear curve. I can see reasons for both choices, but I'd probably go with Googles to avoid the sharp corners. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
In message 32c69001-db69-46c4-905f-d994b017b...@tcs.wap.org, Jonathan E. Hardis writes: That box of Wheaties that is labelled 'Net Weight 10 oz' would correctly weigh 10 oz everywhere on Earth, on the Moon, and on the ISS. It does not. For several reasons, but mainly because the enclosed air changes means that the bouyancy depends on air-pressure and thus altitude. That goes for anything which isn't enclosed by a rigid container with neglible elasticity in the range of relevant air-pressures. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
LEAPSECS leapsecs-boun...@leapsecond.com wrote on 05/19/2015 05:49:23 PM: From: Eric R. Smith ersm...@hfx.eastlink.ca To: Leap Second Discussion List leapsecs@leapsecond.com Date: 05/19/2015 06:19 PM Subject: Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News Sent by: LEAPSECS leapsecs-boun...@leapsecond.com On 19/05/15 05:39 PM, Joseph M Gwinn wrote: From: Poul-Henning Kamp p...@phk.freebsd.dk To: Leap Second Discussion List leapsecs@leapsecond.com, Hal Murray hmur...@megapathdsl.net Date: 05/19/2015 02:22 PM Subject: Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News Sent by: LEAPSECS leapsecs-boun...@leapsecond.com In message 20150519181135.cacbe406...@ip-64-139-1-69.sjc.megapath.net, Hal Murray writes: I think the problem is conflicting standards. POSIX doesn't agree with UTC. Not so much doesn't agree as ignores. No, it's Doesn't Agree - the issue was very much debated. True UTC (with leap seconds) didn't cure a problem the committee cared about, and managed to cause problems they did care about. In short, POSIX systems have to be able to work in a cave, with no access to the sky or knowledge of astronomy. If POSIX time_t were actually a count of SI seconds elapsed since the epoch, then a machine in a cave (with an accurate enough clock) could in principle maintain correct timestamps. As it stands though, POSIX time_t cannot be implemented without access to a UTC reference of some kind, i.e. access to the sky. Well, while POSIX mentions SI seconds, the standard is careful to say that these seconds are not exactly SI seconds (because UNIX workstations can have pretty bad clocks). And the standard specifically disclaims being UTC, despite the appearance. Read the standard carefully. It is intended and designed to support isolated operation. Joe Gwinn___ 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
On May 19, 2015, at 3:02 PM, Richard Clark rcl...@noao.edu wrote: It was around the late 1600's that it started becomming possible (and necessary) to decouple weight and mass. The sound you hear is the sound of chalk screeching on the blackboard. “Weight” is an ambiguous term that can either mean “force” or “mass.” If you believe physics textbooks since the dawn of the space age it means “force.” If you believe the weights and measures community—including every box of breakfast cereal you’ve seen since the dawn of the space age—it means “mass.” That box of Wheaties that is labelled “Net Weight 10 oz” would correctly weigh 10 oz everywhere on Earth, on the Moon, and on the ISS. Both uses of the term are correct. Indeed, it was not until the 3rd CGPM decided the matter in 1901 that the “kilogram” was officially recognized as a unit of mass, rather than force. And since in the United States the pound (lb, as distinct from lbf) is, by definition, a specific multiple of the kilogram, it too is a unit of mass—regardless of what one might read in physics textbooks. The best guidance on this subject is avoid the use of the term “weight” as much as possible. Failing that, please see section 8.3 in http://physics.nist.gov/cuu/pdf/sp811.pdf http://physics.nist.gov/cuu/pdf/sp811.pdf . - Jonathan ___ 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
On 2015-05-19 08:10, Stephen Colebourne wrote: A key point I've been making all along is that there needs to be an internationally agreed standard for how to do the smoothing. In Java I recommended UTC-SLS simply because it was at least a written up approach. (My preference is for a linear change because there is less chance of implementors getting it wrong). What for? I consider all these schemes just as internal representations of UTC time stamps, chosen according to special needs and constraints. We would not have so many different internal representations if there was no need for them. For data interchange and external storage, We have the standardized and well-understood notation of ISO 8601 for time stamps with leap seconds, such as 2015-06-30T23:59:60.2Z. Every internal representation must be convertible to and from that standard. In my opinion, no other standard is needed. Michael Deckers. ___ 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
In message 20150519181135.cacbe406...@ip-64-139-1-69.sjc.megapath.net, Hal Murray writes: I think the problem is conflicting standards. POSIX doesn't agree with UTC. Not so much doesn't agree as ignores. Are there any examples of buggy standards with a huge installed base getting fixed? Yes, plenty. Building codes. Electrical codes. Traffic codes. The deciding factor is always number of people killed and maimed. ... Or the rich loosing money, that always gets political action. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
Standards are funny things. Sometimes they get adopted and sometimes they don't. Sometimes more than one standard becomes the standard. The leap seconds debate exists because there are two entirely reasonable ways to talk about time, one based on the sun and one based on atomic clocks. The solar form has, over thousands of years, created the view that there are always 86400 seconds in a day, ignoring DST. Given this, API writers like my self (Java) have no choice but to provide developers with an API view where there is never ever an instant where second-of-day = 60. Developers, like most humans, prefer the fiction that every day has 86400 subdivisions called seconds, whether true or not. From my perspective, the unwillingness to accept or create a UT-86400 time scale, and define its link to UTC, is very problematic. I also think it is the root of a solution to this sorry saga. Stephen On 19 May 2015 at 17:05, Warner Losh i...@bsdimp.com wrote: 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? Warner On May 19, 2015, at 2:10 AM, Stephen Colebourne scolebou...@joda.org wrote: A key point I've been making all along is that there needs to be an internationally agreed standard for how to do the smoothing. In Java I recommended UTC-SLS simply because it was at least a written up approach. (My preference is for a linear change because there is less chance of implementors getting it wrong). We would also need an agreed name for a time-scale that is aligned with UTC most of the time but that always has 86400 subdivisions of the day (rubber seconds). The lack of a name for this (something which I strongly believe is desired) is very frustrating. I'd suggest UT-86400 as a starting point for a name. Stephen On 19 May 2015 at 07:20, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message dce2e991-a54d-42af-98f8-2d5087fbf...@leapsecond.com, Tom Van Baak writes: https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ So already here the trouble starts: Google uses a smooth curve for their clock-smearing and Amazon uses a piecewise linear curve. I can see reasons for both choices, but I'd probably go with Googles to avoid the sharp corners. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ 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
On 05/19/2015 12:05 PM, Warner Losh wrote: 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? Because POSIX requires you to pretend leap seconds don't exit. ___ 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
LEAPSECS leapsecs-boun...@leapsecond.com wrote on 05/19/2015 02:22:24 PM: From: Poul-Henning Kamp p...@phk.freebsd.dk To: Leap Second Discussion List leapsecs@leapsecond.com, Hal Murray hmur...@megapathdsl.net Date: 05/19/2015 02:22 PM Subject: Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News Sent by: LEAPSECS leapsecs-boun...@leapsecond.com In message 20150519181135.cacbe406...@ip-64-139-1-69.sjc.megapath.net, Hal Murray writes: I think the problem is conflicting standards. POSIX doesn't agree with UTC. Not so much doesn't agree as ignores. No, it's Doesn't Agree - the issue was very much debated. True UTC (with leap seconds) didn't cure a problem the committee cared about, and managed to cause problems they did care about. In short, POSIX systems have to be able to work in a cave, with no access to the sky or knowledge of astronomy. Are there any examples of buggy standards with a huge installed base getting fixed? Yes, plenty. Building codes. Electrical codes. Traffic codes. The deciding factor is always number of people killed and maimed. Yes. I always tell people that the US Electrical Code is written in blood. The blood of the hapless. ... Or the rich loosing money, that always gets political action. This actually supports standards, in an odd way: People who want to do the right thing (whatever that may be) don't want to be punished for this by their less fussy competitors. If one puts safety standards in law and enforces them, the problem is solved. Joe Gwinn___ 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
On 19/05/15 05:39 PM, Joseph M Gwinn wrote: From: Poul-Henning Kamp p...@phk.freebsd.dk To: Leap Second Discussion List leapsecs@leapsecond.com, Hal Murray hmur...@megapathdsl.net Date: 05/19/2015 02:22 PM Subject: Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News Sent by: LEAPSECS leapsecs-boun...@leapsecond.com In message 20150519181135.cacbe406...@ip-64-139-1-69.sjc.megapath.net, Hal Murray writes: I think the problem is conflicting standards. POSIX doesn't agree with UTC. Not so much doesn't agree as ignores. No, it's Doesn't Agree - the issue was very much debated. True UTC (with leap seconds) didn't cure a problem the committee cared about, and managed to cause problems they did care about. In short, POSIX systems have to be able to work in a cave, with no access to the sky or knowledge of astronomy. If POSIX time_t were actually a count of SI seconds elapsed since the epoch, then a machine in a cave (with an accurate enough clock) could in principle maintain correct timestamps. As it stands though, POSIX time_t cannot be implemented without access to a UTC reference of some kind, i.e. access to the sky. Regards, Eric Smith ___ 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
In message 0e448a0c-f75a-43a0-9fb6-7d715ef92...@bsdimp.com, Warner Losh writes: 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? Speaking of flawed... Reported to me from the hall-way-track at the last WP7A meeting: The main drive to ditch leap-seconds comes from the only country ever to flunk Metric-101 rimshot/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
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? Warner On May 19, 2015, at 2:10 AM, Stephen Colebourne scolebou...@joda.org wrote: A key point I've been making all along is that there needs to be an internationally agreed standard for how to do the smoothing. In Java I recommended UTC-SLS simply because it was at least a written up approach. (My preference is for a linear change because there is less chance of implementors getting it wrong). We would also need an agreed name for a time-scale that is aligned with UTC most of the time but that always has 86400 subdivisions of the day (rubber seconds). The lack of a name for this (something which I strongly believe is desired) is very frustrating. I'd suggest UT-86400 as a starting point for a name. Stephen On 19 May 2015 at 07:20, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message dce2e991-a54d-42af-98f8-2d5087fbf...@leapsecond.com, Tom Van Baak writes: https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ So already here the trouble starts: Google uses a smooth curve for their clock-smearing and Amazon uses a piecewise linear curve. I can see reasons for both choices, but I'd probably go with Googles to avoid the sharp corners. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Look Before You Leap – The Coming Leap Second and AWS | Hacker News
Several years ago (2000ish) I came across a website arguing why the US is right to not adopt the metric system. (I suspect the author had never heard the term SI) One of its examples of how the metric system is bad was its confusing use of two units, the newton and the kilogram, to measure weight. The US system is so much simpler and sensible with just one unit, the pound. It was around the late 1600's that it started becomming possible (and necessary) to decouple weight and mass. Yet there is still confusion and sloppines in the general public (and operators of Mars bound spacecraft) dealing with the two. It's less than a century that it started becomming possible/necessary to decouple the Earth's rotation from time. So, am I optimistic about the chances for a quick resolution to the leap second problem? Richard Clark On Tue, 19 May 2015, Poul-Henning Kamp wrote: ... Speaking of flawed... Reported to me from the hall-way-track at the last WP7A meeting: The main drive to ditch leap-seconds comes from the only country ever to flunk Metric-101 rimshot/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News
https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ https://news.ycombinator.com/item?id=9567761 /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News
Also: http://www.wsj.com/articles/markets-are-jumpy-over-coming-leap-second-1431988248 and http://www.wsj.com/video/forget-leap-year-what-a-leap-second/EED69170-D317-424C-BF6C-4AEAB827473A.html - | Richard B. LangleyE-mail: l...@unb.ca | | Geodetic Research Laboratory Web: http://gge.unb.ca | | Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142 | | University of New Brunswick Fax: +1 506 453-4943 | | Fredericton, N.B., Canada E3B 5A3| |Fredericton? Where's that? See: http://www.fredericton.ca/ | - From: LEAPSECS leapsecs-boun...@leapsecond.com on behalf of Tom Van Baak t...@leapsecond.com Sent: Monday, May 18, 2015 11:59 PM To: leapsecs@leapsecond.com Subject: [LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ https://news.ycombinator.com/item?id=9567761 /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
