Seriously, there is no knives in any kitchens in those jurisdictions ???
Seriously, there is no knives in any kitchens in those jurisdictions ???
Every children could take a knife in a kitchen, and most of those knife will probably be more lethal than a plastic gun, without any building effort.
GPS and PTP both broadcast TAI and UTC-TAI that sum up the past leap seconds, so your claim is not completely correct. I will add that GPS and PTP both lack a method to broadcast the leap second history table required to safely compute time in the past at the second precision. NTP need a major protocol upgrade to fix his multiples issues, or PTP need to be broadcasted as NTP is today.
It's not the usual process of ITU decision that is the cause of the rejection. The cause is the fact that the proposition itself is stupid and make the problem even worst. To be certain that the programmers take seriously the fact that the duration of day is variable the adjustment code path must occur more often. The most effective way will be to define the civil time by a day counter and a offset since the start of that day. The day duration can be adjusted periodically. The programmed will know that the day is not 86400 second and the day increment code path will be tested every night.
1) Will lead to many more confusion between the two type of seconds.
2) Will break the ancestral definition of time in all the civilization that ever existed.
3) The only way and nobody is seriously make any other proposition. The discussion is how to improve it because the leap second is rare enough to make too many programmers not taking it seriously enough and testing is enough.
So the solution is certainly not to make the adjustment more rare, but more often. My proposal is to define the civil time by a day counter and a offset since the start of that day. The day duration can be adjusted periodically to match the average earth rotation and the day increment will occur every night so the programmed need to be aware of it and can test it every night. As a bonus it will work on any planets.
I think we need to switch to a day counter and a offset since the beginning of that day to match the physical reality of the earth rotation.
Yes this will make the programmer lazy about the problem and a big mess when the first change take reality. I largely prefer a model with a day counter and a time offset since the start of that day, so the day duration can be adjusted to the physical reality of the earth rotation. The advantage is that the programmer can test the day increment every night.
The current leap second system is still enough for many centuries and even several thousand of years is the leap seconds are allowed every months or weeks.
Is you think about this more deeply you will realize that the best model will be to have what we actually call UTC defined in term of days counter since a epoch date and a second counter since the start of that day. This will allow to adjust periodically the day duration to the reality of the average earth rotation. Not only this model work with the earth rotation any time in his history, but it will work with any planets.
But no matter what, programmer that can't directly use TAI only will have to deal with variable day duration and historical day duration table. At least it will be more easy to test because the difficult part occur every day.
Yet no one have found a better way to coordinate some important aspect of the worldwide telecommunication infrastructure. Keep in mind that there have to deal with governments with opposed sensibility or in conflict.
The industrial/embedded systems you describes must use TAI, not UTC or local time. Actually only the GPS broadcast the TAI in a direct usable form nearly everywhere. NTP broadcast UTC only and fail to send the TAI to UTC offset. PTP doe the right thing but is actually not broadcasted as NTP or GPS is.
Exactly, you got it right. What's depressing is that, even after decades, POSIX is still unfixed.
Sorry, in the previous comment I have wrote "Nexus 5P" while I must have wrote "Nexus 5X". I was confused by the Nexus 6P, but the one I own is the Nexus 5X. That said, I don't think this will affect the observations.
I have the N770 N800 N810 N900 N9 Nexus S, and now the Nexus 5P since a week. Of course the technology of the Nexus 5P completely surpass the N9, but from the UI point of view I found the Nexus S unusable even after upgrading to Android 4.3. The Nexus 5P is much better in many point but still far far away from the N9 UI design. Some random observations:
* The N9 always display the time and important status when his proximity sensor don't detect light reflection from a pocket. I just have to look at it to know the time and if I have a received a message, not even to touch it. The N9 laminated OLED display on curved edge glass have a ultra low power mode that allow to let some pixels in on state while the main processor is in sleep mode. The Nexus 5P need a least to be inclined for a least 1 second to make it display something. The Nexus 5P seem to be a LCD screen with a backlight on the the full surface even when displaying only the time.
* The N9 is outrageously conformable to hold in the hand. It has no corners in the contact of the hand and the transition from the case to the curved screen edge is almost imperceptible. Never found a better phone case design to date.
* The N9 react to a double tape on the screen with a finger by displaying a home screen and give direct access to the other main screens with a swipe in the good direction. The Nexus 5P is not reacting to any touch screen solicitation, the only way is to touch a button or the fingerprint scanner.
* The N9 UI navigation is deadly simple and extremely effective. Simply swipe from the edge of the screen from any application to go to the application menu, application switching menu, or the status feed screen. The Nexus 5P Marshmallow Android have the round and square button to do almost the same but it's less comfortable because there are at the bottom of the screen. The swipe of the N9 can be done anywhere along the edge of the screen, and when you use a single hand to hold and operate the device it's more quick and comfortable to swipe on the region near the top of the screen.
* The N9 allow to close an application by simply swipe it from the top to the bottom direction, so effective. The Marshmallow require to first go to the application switching menu.
* The N9 present a small view of the full applications screens in the application switching menu, in two selectable size. This make the selection of applications far more quick and easy than the rolling applications selector of Marshmallow.
* The N9 can act as a fully normal and very fast USB memory. I have not yes tried this with the Nuxus 5P (because his box don't include a USB type A cable), but I Android killed this feature sometime after the Nexus S. I found the two replacement protocols unstable and boringly slow on the Galaxy S3 for example.
* The N9 fully integrate the socials network into this core feature applications like only the last Android try to do. Still the way Skype is integrated into the N9 is vastly superior as the contacts and messages notifications are fully merged with the system. With the N9, the application or protocols used to send and receive call and messages are just a details on the configuration of the accounts settings. After that, the core system take care of the detail for you and present all the protocols with the same framework. From my point of view this was the most advanced feature of the N9, still far away ahead of the last Android.
Overall, the N9 is still a reference in surprisingly number of points even 5 years after his release and murder.
I don't see your points about who needs to participate and skipping, those was never the problem in the situation I observed.
The point is that if "agile" is not the solution, then we have to use an other method, proving by the way that "agile" is not related to "scrum". I was not talking about "agile", you introduced the notion in this context.
Real life is something different. There is a lot of situations where it's critically required to deliver a exploitable solution in a few days, if not in a few hours. In that stress it's unthinkable to talk about changing the design. And this is exactly in this kind of stressed situation that managers call for everyday scrum. I have observed that a number of times, and even, as a project leader, was sometimes contractually obliged to make this kind of scrum and to report the progress to the customer.
We're here to give you a computer, not a religion. - attributed to Bob Pariseau, at the introduction of the Amiga