21 comments

[ 4.3 ms ] story [ 56.7 ms ] thread
That has to hurt. I would really love to read an in–depth analysis of the problem.
One engineer: do we need to account for leap year?

Other engineer: it wasn’t in the specs.

It was probably a manager that said it wasn’t in the spec, but yea, that is entirely plausible :(
Yep. I’ve heard that one before. Either they have a lack of common sense or they stopped caring enough to ask questions.
rolling your own time library is as crazy as rolling your own crypto
To be fair most time libraries suck and can't handle fairly basic operations. For instance, if you're using python's datetime module and want to get the start/end dates of the current month, you need to "roll your own" like

    now = datetime.now()
    month_start = date(now.year, now.month, 1)
    month_end = date(now.year, now.month + 1, 1) - timedelta(days=1)
So in Dec your code hits month 13? Kinda funny in a post how rolling your own time library is easy we made trivial bugs
(comment deleted)
That's the point. I'm not advocating rolling your own date logic, only pointing out how easy it is to for "roll your own" logic to make its way into code even if if you're using a datetime library.
If you're going to copy my code onto HN I would appreciate attribution.

/s

You probably haven`t used phps Carbon.
You should use: calendar.monthrange
The typical time libraries don't deal with satellites. Clocks are running at a slightly different rate in orbit.
The root cause was identified as a software issue within the ground segment
Yes, a thing that interacts with satellites, where you would expect that code to be.
Some degree of effort is required to _not_ use et (Ephemeris Time) and, by practice, a spacecraft clock adjustment (SCLK) would be initially loaded.

The developers would have gone through this routine (initially load SCLK, use Ephemeris Time) literally _thousands_ of times in their coding, developing ... preparing, making .... careers. It's the SPICE baby.

so .... WTF?