Eutelsat OneWeb blames 366th day for 48-hour date disaster
- Reference: 1736176925
- News link: https://www.theregister.co.uk/2025/01/06/eutelsat_oneweb_leap_year/
- Source link:
The satellite broadband service fell over on December 31, 2024, for 48 hours. [1]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."
[2]
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 [3]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.
[4]
[5]
Eutelsat OneWeb, a Starlink competitor, completed its low Earth orbit (LEO) constellation in 2023. The company has more than 630 satellites, far fewer than the thousands of Starlink spacecraft, but enough to maintain connectivity. Assuming the code on the ground knows about leap years.
[6]India's space gatekeepers pick Eutelsat OneWeb to provide satellite broadband
[7]BT and OneWeb deliver internet to rock in Bristol Channel – population 28
[8]OneWeb lofts last batch of satellites to enable global internet service
[9]OneWeb takes $229M hit from satellites not returned by Russia
The outage came on the [10]25th anniversary of the Y2K panic , in which the promised chaos did not unfold due in large part to the endeavors of IT teams working on the problem during the preceding years.
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.
[11]
SpaceRISE has promised the project will be launched into service by early 2030. Luckily, that is not a leap year. ®
Get our [12]Tech Resources
[1] https://oneweb.net/resources#/pressreleases/eutelsat-statement-on-oneweb-temporary-outage-3362232
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z3wMM4V9VxBt4bCF0Goy1wAAAII&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2024/02/29/fuel_pump_leap_year_bug/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z3wMM4V9VxBt4bCF0Goy1wAAAII&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z3wMM4V9VxBt4bCF0Goy1wAAAII&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2023/11/24/eutelsat_oneweb_india/
[7] https://www.theregister.com/2023/07/24/bt_oneweb_lundy/
[8] https://www.theregister.com/2023/03/27/oneweb_satellite_deployments/
[9] https://www.theregister.com/2022/09/05/oneweb_takes_229m_hit_from/
[10] https://www.theregister.com/2025/01/02/twentyfive_years_y2k/
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z3wMM4V9VxBt4bCF0Goy1wAAAII&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[12] https://whitepapers.theregister.com/
Rocket Science
It seems that rocket science is easier than terrestial date calculations.
Re: Rocket Science
Like I always tell junior programmers, dates and times are hard. Always use the system libraries, never roll your own date/time code.
At least then when something goes wrong you can blame Microsoft or whoever supplied said libraries.
Re: Rocket Science
Dates would be easier if they were actual objects.
We've been using object-oriented programming for decades now, but dates are still stored as a fucking string.
With the seperator.
Do you have any idea how many different seperators are used all over the world ? I have found these : / - . \ ! (and when I say found , I mean having to repeatedly debug code that was working fine until a new use case was found).
If date/time values were stored as proper objects, with Year, Month, Day, Hour, Minute, Seconds, Milliseconds, and recoverable with the proper routines, then I strongly believe that all this kind of fuss would be eliminated.
But, even though Redmond is on version 11 of its perenially buggy software, it would apparently be too much of a hassle to record date/time values as the objects they are.
So we continue to get fucking strings, and having to parse them every time .
Re: Rocket Science
There is an international standard for date formatting, ISO 8601:
"When dates are represented with numbers they can be interpreted in different ways. For example, 01/05/22 could mean January 5, 2022, or May 1, 2022. On an individual level this uncertainty can be very frustrating, in a business context it can be very expensive. Organizing meetings and deliveries, writing contracts and buying airplane tickets can be very difficult when the date is unclear.
ISO 8601 tackles this uncertainty by setting out an internationally agreed way to represent dates:
YYYY-MM-DD
Therefore, the order of the elements used to express date and time in ISO 8601 is as follows: year, month, day, hour, minutes, seconds, and milliseconds.
For example, September 27, 2022 at 6 p.m. is represented as 2022-09-27 18:00:00.000."
https://www.iso.org/iso-8601-date-and-time-format.html
Laugh or cry?
Well, the West has only had a calendar system with leap years in it for a smidge over 2000 years - such radical changes sneak up on people.
Re: Laugh or cry?
Why worry over a single day when the original calendar was out by 11 days by the mid 18th century?
Re: out by 11 days by the mid 18th century?
Only in a couple of European countries and in the West, only Britain. E1R had been advised by John Dee to switch, but she thought she'd have too much opposition in the Privy Council. She didn't always get what she wanted.
Someone's
days are numbered.
TFF
Is this the same OneWeb that was going to deliver a British Brexit GPS? (Let the lion roar, etc.)
Re: Laugh or cry?
The west had it easy. Have pity with the Ottoman Empire: Tax revenues were linked to the harvest, so the solar calendar. The soldiers and the bureaucrats were paid according to the Islamitic calendar linked to the phases of the Moon.
From time to time this discrepancy led to an empty treasury.
Oh FFS.. It's coding 101
That is all.
You would think....
....it would fail over on 02/29.
I wonder if this was because they hired someone from Alphabet/Google who then decided to smear the 366th day instead of counting it?