Arthur T Knackerbracket has processed the following story:
Eutelsat's OneWeb constellation suffered a date-related meltdown last week while the rest of the IT world patted itself on the back for averting the Y2K catastrophe a quarter of a century ago.
The satellite broadband service fell over on December 31, 2024, for 48 hours. According to Eutelsat, "the root cause was identified as a software issue within the ground segment." Issues began just after 0000 UTC, and it took until January 1 to get 80 percent of the network operational. By the morning of January 2, everything was working again.
A spokesperson told The Register: "We can confirm that the issue was caused by a leap year problem, related to day 366 in 2024, which impacted the manual calculation for the GPS-to-UTC offset."
An issue related to the number of days in a leap year will have many software engineers stroking their chins thoughtfully. While it is usually the extra day itself that can cause the odd issue or two, failing to take it into account when rolling into a new year can also cause headaches, as evidenced by OneWeb's woes.
[...] The issue faced by Eutelsat OneWeb was not due to two digits being used to store the year, which is what happened in the Y2K incident, but rather an oversight that meant the extra day in a leap year was not adequately accounted for. Since accurate timekeeping is required for communication and navigation systems, problems with the offset would cause an understandable – if not excusable – service outage.
The good news is that the problem was in the software in the ground segment, meaning that the hardware in orbit was unaffected. However, the incident is embarrassing for Eutelsat since it is one of the leaders of the SpaceRISE industry consortium, recently tapped by Eurocrats for the multibillion-euro IRIS² satellite broadband deal.
(Score: 5, Funny) by Tork on Friday January 10, @09:13PM (1 child)
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by mcgrew on Saturday January 11, @10:16PM
You know who else? One 17th century clockmaker. I've read of a clock made in the 1600s in France that gave the time and date, and accounted for leap years, including the odd cases.
I'd give a link, but I saw it a long time ago and Google is no help finding even a mention, let alone a citation.
A man legally forbidden from possessing a firearm is in charge of America's nuclear arsenal. Have a nice day.
(Score: 0) by Anonymous Coward on Friday January 10, @09:22PM (1 child)
I once spoke to a guy who worked in the space industry. He told me a horror story about a major project that was late and he went on it to rescue it. There wasn't even a makefile for the source code. It was due for launch and no one could recompile it until he fixed it. The launch slipped a few months. These Rocket Scientist(TM) types live in a bubble and they think they know best.
(Score: 0) by Anonymous Coward on Saturday January 11, @03:15AM
Interesting, so far. Which space project was it? What did the code do?
(Score: 4, Informative) by pTamok on Friday January 10, @10:25PM (8 children)
Time for me to point out things that are not obvious about dates (and times)
Infinite Undo!: Falsehoods programmers believe about time [infiniteundo.com]
Infinite Undo!: More falsehoods programmers believe about time; “wisdom of the crowd” edition [infiniteundo.com]
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca [github.com]
(Read the comments)
QuirksMode: Making 'time' safe for historians [quirksmode.org]
This does not excuse the fact that the programmers got things wrong, but it does point out that dates (and times) are more difficult that they first appear.
Years can (and do) have more than 365 days
Years can (and do) have more than 52 week labels.
Yes, there was an historical year with a 30th February. (30 February 1712, in Sweden)
An hour can have more than 60 seconds, and indeed some have
Hours can potentially have fewer than 60 seconds
(Score: 4, Funny) by janrinok on Friday January 10, @10:34PM (2 children)
A typo !!!
Most hours have more than 60 seconds - in fact I think they all do. Which also implies that no hours can have less than 60 seconds.
But the point was well made....
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 2) by Tork on Saturday January 11, @04:24AM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2, Interesting) by pTamok on Saturday January 11, @10:38AM
Yes, well spotted. I was in 'I'm tired and in 'need to go to bed, but I just want to do this one thing on the Internet...' mode'.
It should have been minutes instead of hours. Leap seconds [leapsecond.com] usually add an extra second to a particular minute, so the seconds counter goes from 59 to 60, followed by 00. GPS time does not implement leap seconds, which is why GPS time is (currently) 18 seconds ahead of UTC, as UTC has inserted an additional 18 seconds as leap seconds.
Leap seconds are added because the Earth's rotation (on average) is slowing down (due to the effect of the tides), so it takes a little more than 24 hours to make one rotation. However, the Earth's rotation is not uniform, in in the past years it has been speeding up (much like an ice skater speeds up a spin by moving their arms from being outstretched to being close to their body, movement of liquid in the Earth's core changes the Earth's moment of inertia) - and it was possible that the Earth would speed up enough that a leap second would be removed from UTC, giving a minute lasting less than 60 seconds. This has not happened yet, and may never do so, depending on how UTC is managed in future (which is a long discussion in itself).
But the original statement is not as wrong as it could be, as there are some pathological examples:
So, yes, most hours are more than 60 seconds long.
Are there any hours fewer than 60 seconds long? That's an interesting question. If you look at the transition between winter-time and summer-time when Daylight Saving Time is implemented the time shewn on the the wall-clock typically goes from 01:59:59 to 03:00:00, which is a discontinuity (that particular time is not monotonic). Does the time jump, or is the hour starting at 02:00:00 of zero duration (and therefore fewer than 60 seconds in duration)?
Similarly, if you put your computer to sleep at, say 13:15:00 and wake it up again at 14:14:45 , it's wall-time clock will jump 59 minutes and 45 seconds. Once you get to 14:15, an hour has passed in reality, but the duration experienced by the computer is 15 seconds. If you have a routine that is scheduled to be executed every 15 minutes, should you (a) drop the ones that were scheduled while the computer was asleep? (b) run the 'missing' ones as soon as possible, one after the other? (c) run the missing ones as soon as possible in parallel? How do you determine which routines have been missed if (a) the computer has moved time-zone or (b) a Daylight Saving Time transition has happened or (c) a leap-second has been added to UTC? What happens if you put the computer to sleep in one time zone and wake it up in a time zone where the wall-clock time is earlier than the time it was put to sleep? Should you run the 15 minute routines twice - once before putting the computer to sleep, and once after? If not, how do you determine when not to run the routine? Add a DST transition as well.
Accounting for all the possible edge-cases in time calculations is not trivial.
(Score: 2) by JoeMerchant on Friday January 10, @11:03PM (4 children)
Dates and times are very complex, and error prone.
Which is why basically everybody programming for them should use proven libraries rather than rolling their own logic.
For my environment EVERYTHING is encoded in int64 Unix time in milliseconds. If there's a reason to come in or out of that, I call the library functions to do the translation, but you'd be amazed how rarely that is necessary outside of specific user input and display.
If you must roll your own calendar logic, be sure to factor in the cost of validation - which is quite high, but orders of magnitude lower than most failures found in the field.
------
A software tester walks into a bar, he orders a beer.
He orders 0 beers.
He orders -356 beers.
He orders 1025 beers.
He orders 102584578367531 beers.
🌻🌻 [google.com]
(Score: 1) by pTamok on Saturday January 11, @11:38AM (3 children)
OK, you triggered me. Sorry...
A software tester walks into a bar, he orders a beer.
He orders 1 bear. (Obviously a Hofmeister [wikipedia.org]. What do you get if you order a Stella [wikipedia.org]?)
He orders -1 beer.
He orders 256 beer.
He orders "1" beer.
He orders "1+1" beer.
He orders 0x01 beer.
He orders 0o01 beer.
He orders +1 beer.
He orders 1+1 beer.
He orders "1"+"1" beer.
He orders 1);DROP TABLE Order; beer.
He orders ① beer.
He orders Ⅰ beer. (Roman numeral)
He orders ⅰ beer. (list item)
He orders one beer.
He orders "a" beer.
He orders U+0031 beer.
He orders ⠼⠁ beer. (Braille, number symbol telling you to interpret the next symbols as numbers and not letters, followed by the first Braille symbol, normally interpreted as 'A', but in this case, '1')
He orders 𝠀beer. (Signwriting [wikipedia.org] - '☝', index finger raised)
He orders & # x 0 0 3 1 ; beer (remove spaces)
He orders beer (Null character, or field not filled in)
He attempts to pay with a combination of Susan B. Anthony, Sacagawea, Sand dollars, and $2 bills.
(Score: 2) by JoeMerchant on Saturday January 11, @03:34PM (2 children)
You're just getting started.
My unit tests that actually find bugs go through messages corrupting one byte at a time and passing the corrupted message for processing.
Then they go one layer in, corrupt the inner message and put a valid checksum wrapper on it. That's the test that catches the most regressions.
🌻🌻 [google.com]
(Score: 1) by pTamok on Saturday January 11, @04:27PM (1 child)
Oh, I realize I was 'just getting started', and your approach looks good. Deliberately breaking protocols to check if their state machines are properly implemented is another good thing to do.
I've found bugs where people don't implement the complete specification: such as using all the allowable characters in each part of an email address; or try putting non-escaped null characters into text input strings, or indeed one of several possible escape characters as the last element of a text input string. Malformed UTF is also fun.
The most irritating bugs I experienced were the Heisenbugs, that manifested in code linked without debug symbols, but did not manifest in code linked with the symbols, which made debugging a chore (this was a long time ago).
(Score: 3, Insightful) by JoeMerchant on Saturday January 11, @05:03PM
My philosophy is to keep (most) debugging accessible during runtime through logging. I grew disenchanted with debug mode when it used to run significantly slower and would often manifest these problems only in release mode. Heisenbugs as you say.
Our logging mechanism is switchable per module, showing only serious warnings and errors in default release mode, but debug and detailed debug messages may be switched on when desired. Too much logging activity will cause it's own problems, but the intelligently focused approach has served me better than compiled in symbols debug mode for a long time.
Now, compiled in symbols for profiling and code coverage is a different thing, and useful in its own ways.
🌻🌻 [google.com]
(Score: 3, Interesting) by gznork26 on Friday January 10, @10:55PM (2 children)
In 1974, I was on contract to an insurance company in Chicago. One of the tasks was to update their code to be able to handle longer dates. At the time, they were using a single digit to indicate the year, and they wanted us to change the code so it was stored as two digits. We told them that they'd have another problem at the end of the century, but they assured us that the COBOL code we were changing would have been replaced by then.
I didn't find out whether that was true, but we did warn them.
Khipu were Turing complete.
(Score: 1) by pTamok on Saturday January 11, @11:47AM (1 child)
So, obviously, you used base64 encoding for the two characters. That would get them to the year 4096. COBOL handles text quite happily, and a lookup table allows conversion from base64 for the display digits.
The routines for doing arithmetic with base64 encoded integers would be slightly more challenging, but it is all do-able.
(Score: 2) by gznork26 on Thursday January 16, @12:55PM
They were just using decimal digits, but I did use a the binary value of characters in an Applesoft Basic database I wrote to be able to use larger numbers in the same space.
Khipu were Turing complete.
(Score: 2) by Snotnose on Saturday January 11, @12:15AM
private fun isLeapYear() : Boolean {
val calendar = Calendar.getInstance()
calendar.set(Calendar.MONTH, Calendar.DECEMBER)
calendar.set(Calendar.DAY_OF_MONTH, 31)
val lastDay = calendar.get(Calendar.DAY_OF_YEAR)
return lastDay > 365
}
I should probably compile/run this before posting. Nahhh...
I put a "Warning: Contains scenes that may be disturbing to some viewers" label on my bathroom mirror.