Hacker News Reader

Comment by SSLy | Hacker News Reader

> A rather amusing situation was encountered with another train set that refused to work on November 21, 2022, despite not being in service at the time. The computer reported a compressor failure, although the mechanics determined that there was nothing wrong with the compressor. Unfortunately, the train still did not raise its pantographs. The analysis of the computer code revealed a condition enforcing the failure, which read as follows:

> if the day is greater than or equal to 21, and

> if the month is greater than or equal to 11, and

> if the year is greater than or equal to 2021

> then report a compressor failure.

View on HN

I guess a charitable interpretation is that the compressor manufacturer set an 'expiry date' to ensure replacement of a vital component.

(but it's probably just shady business.)

Also the wrong way to implement an expiry data, since it'd work fine again when the day goes below 21 or month below 11, even if the year is 2021 or greater - which seems to be what happened if they only noticed it in November 2022 rather than 2021.

It might lead to a fault that appears more realistic - it'll go away for a bit in December before coming back again... if the engineers say the compressor's good but the computer fails it intermittently, that seems like a good point to get the manufacturer involved which is what they wanted to force

Very charitable. The "expiry date" was set to the next servicing date and there was no way for competition to fix this hardcoded date and this was not documented in the official documents. Clearly a way to force buyers to use the "official" service.

Reminds me of those work arounds for share ware in the 2000s,when I you had to say the system time back

Yeah, that's not a component expiry date. This reads more like "fire a warning shot in November, and then fuck the operator over during Christmas". It feels like trying to maximize damage, as 21-31 December is exactly where a huge chunk of population travels to visit their family homes, and many of them do so via trains.

Nah... I just bet that this is some dev, that doesn't know how to deal with dates.

I had a recently "senior" dev give me a SQL query with similar where clause, when asked to query data after Sept 1, 2022 (where moy >= 9 and dom => 1 and year => 2022)

In case anyone is confused, the problem is that dates loop, such that moy=1, dom=1, year=2023 will not match despite being greater than Sept 1, 2022. Technically, then, if you wanted this logic to work you would have to add a second “or” clause that handles the edges missed, e.g. (moy >= 9 AND year = 2022) OR (year > 2022) though you would need a different edge case if your dom wasn’t 1. The easier approach, of course, is to just compare dates or timestamps directly.

What good reason is there for hard coding dates that shutdown trains?

That's when the compressor's going to fail, obviously. ;D

Right. How did that famous adage go? "The best way to predict the future is to invent it."

The best way to predict a crime is to commit it.

(with apologies to Alan Kay who coined the original saying)

Orginally, this train was schedulded to go to depot for maintenance on 21.11.2021, but it broke down a few days earlier and was sent to this bigger maintenance until after New Year. But because of this ifs structure, it stopped out of depot a year later, unintentionally.

broke: the lifespan of this moving part is measured in operational hours

woke: this part will be reported as broken during the last week of november and december, 2022 ONLY.

The real crime is not using a standard date time library and a simple > 2021-11-21

Even being evil requires a certain level of competence. It's how we actually catch any of them.

Can be often problematic on PLCs and the programming environment exposed to programmer.

This was programmed into a PLC, not traditional code.

PLCs are basically environments designed for mere technicians being able to adjust code in very clear concise fashion. It can be way more verbose, but the logic is clear and solid for decades of operation.

It doesn't require reading an api documentation on version X of a library downloaded from NPM 15 years ago nor rebuilding an entire project to the latest dependencies.

This is a reason why it was detected a year later - the train service was delayed and it spent late November and whole December in service. So the "expiration" intended for 2021 only manifested in 2022.

Personally I prefer measuring time as seconds that have passed since January 1st, 1970.

And then your train is 32bits and stops working in 2038 ;-)

A reason to code it like this is to avoid that specific date to appear in the compiled code.

I’d speculate it’s more likely incompetence than intentional obfuscation

Technically it's a lot of specific dates Nov 21-30 2021, Dec 21-31 2021, Nov 21-30 2022, Dec 21-31 2022, etc...

Reply on news.ycombinator.com