On Jul 3, 2012, at 10:59 AM, Saku Ytti wrote: > On (2012-07-03 10:11 -0700), Owen DeLong wrote: > >> Trading one known set of bugs for a (probably) larger set of unknown bugs is >> not my definition of progress. Cost without progress is harmful and should >> be avoided. > > Leap bugs are NOT known. Most people have no idea unixtime is not > monotonically increasing. > I had no idea myself until sunday, I had assumed we really go 59 -> 60 -> > 00, but we go 59 -> 59 -> 00. So 59.1 can happen before or after 59.2. > To me this is fundamentally and inherently broken. > > It's quite hard to find code which stores timestamp and then compares it in > future to timestamp which assumes time can travel backwards. > Most bugs are just things that should last 5s last 6s or 4s, but certainly > the bugs exist and developers were not aware that they exist. > > > -- > ++ytti
If you don't know that time is not monotonically increasing, then that only becomes a software bug when you codify your own ignorance into software you write. It is well known that leap seconds exist. The rotation of the planet does not line up well with the orbit of the planet and neither of these lines up particularly well with the rotation and orbit of the moon. Since we have a long standing tradition of using the orbit of the earth to determine years and the orbit of the moon to divide years into months, we use some fudge-factors on the months to make years and months line up. (12 true months would leave us several days short of a complete orbit at the end of the year and seasons would migrate.) Since we have a tradition of measuring diurnal and other repetitive cycles (days) based on the rotation of the earth, we end up with fudge factors to make that line up with months from time to time. (leap seconds). So it goes. Time is much more complex than many people realize. If you write software where time matters, it is your responsibility to learn about these things. Owen
