iggldiggl

But for most people those associations are very useful and actually a desirable property.

Besides, even if you switched to some new, completely-blank-slate system of tracking time, those associations would quickly redevelop since presumably most people will predominantly deal with local events within their own time zone. Only now with added confusion when you do encounter a foreign time reference after all…

The thing is, those "global time" proposals don't change anything about the fact that you have to look up local time and/or local customs when scheduling events in foreign timezone – you have to do it today, and you still have to do it even with a single global wall clock time.

The only thing it does – resolve some potential (potential, not definite!) ambiguity around what (wall clock) time exactly cross-time zone events are taking place, but at the price of completely breaking any association between clock time and the solar day. Personally, I don't think that's worth it.

> "School starts @740"

Which precisely illustrates the problem – because you didn't mention a location, that sentence is now completely meaningless. If I encountered it in a random story – does it mean that it is in the morning (but early morning or late morning or what?), is it in the afternoon…?

Like I said, I posit that most people regard the association between clock time and solar time as an advantage, not as a drawback.

> You could easily have a 'multiple calendar days during one solarday' situation.

I didn't say that this doesn't already happen today, but today it affects far fewer people in mostly less important ways.

> and 3. how to ensure that the train (driver).

That should have read "how to ensure that the train (driver) follows the directions given by the signalling".

And as of now, I suppose that RCAS (or RCAS-like systems) is best suited for (especially minor) single track branch lines that don't currently have a full-scale signalling system already up-and-running, but instead still rely on "Timetable & Train Order" and similar systems.

Single track means that at least outside of stations, collisions can be reliably identified without much danger of false positives (and for station areas you can just institute a blanket speed limit to compensate for the gap in RCAS coverage, which might not even be any lower than the speed limit required for traversing diverging/spring-operated/hand-operated points there anyway), and no already existing full-scale signalling system means that RCAS actually provides a significant safety benefit and is therefore likely worthwhile from a cost-benefit-analysis point of view, too, if you're actually regularly operating multiple trains simultaneously on that kind of infrastructure.

Whereas on multi-track mainline railways avoiding false positives is much harder and normally you should already have proper signalling and train protection systems in place anyway, so the additional safety benefits of RCAS would be much more marginal.

> If we can design self-driving cars, that operate safely in far less controlled environments

Self-driving cars aren't supposed to drive quicker than they can look ahead, which makes the problem way easier because you don't have to figure out how to detect obstacles ahead of time and can simply rely on vehicle-local information to stop if necessary. And because cars can brake way more rapidly than trains, it means you can still drive reasonably quickly even within that limitation.

Plus in an emergency, cars have steering as an additional degree of freedom to attempt getting out of any nasty situation that may have developed.

(And of course the socially expected safety standards for cars are quite a bit lower than for public transport…)

Trains on the other hand have braking distances on the order of a kilometre or so, and high-speed trains at full speed several kilometres, so trying to get by on local data only is hopeless and the usual strategy is instead having central signalling system that can accurately track trains and coordinate their movements.

Yes, but as long as the central signalling system is working, it already knows where the train is, with no need to involve GPS. (And where modern signalling and train protection systems need increased precision as compared to the granularity of track circuits/axle counter sections, the solution usually involves a combination of on-train odometry plus track balises at occasional intervals in order to reset any inaccuracies that might have accumulated.)

What we're talking about here is some sort of TCAS-equivalent for the case where the central signalling is down – while it's easy to accurately localise trains with the aid of a central signalling system that authoritatively knows about the infrastructure layout, it's quite more difficult when you're trying to do the same thing in a decentralised, train-local fashion.

> It's very approximate.

Yeah, but within that approximation it's still very useful to be able to immediately have a rough idea without having to explicitly look it up each time. Plus like I said, calendar date/weekday changes happening during the middle of the day would be the much bigger annoyance…

> TPWS is where a little light comes on saying it would be a good idea to brake now because you passed a signal at danger. Only very fancy versions of TPWS will actually apply the brakes for you.

You're confusing AWS and TPWS – AWS is the older system (based on pre-WW II technology but only deployed nationwide after WW II) which sort of roughly fits your first sentence, while TPWS will actually stop you if you're trying to pass a signal at danger (with the caveat that most automatic signals on the plain line aren't fitted on the basis that a train will relatively rarely actually have to stop at one – statistically that's absolutely sensible if you only have a limited amount of money and want to cover the higher risk signals first, but unfortunately the recent Elstow train crash did manage to hit that particular gap in the system…).

> But even then, an inquiry asked to look specifically into ATP determined we were right to reject it, it was just Too. Fucking. Expensive.

But you did eventually get TPWS which does deliver a quite large fraction of the safety benefits of ATP at a significantly smaller fraction of the costs.

You're conflating multiple things – 1. train detection (which can be track circuits, as described by you, axle counters or on the most modern systems even train-based train detection), 2. how to transmit the stop/go information to the train (driver), and 3. how to ensure that the train (driver).

LZB (the "German system that is more advanced that basic electrical fault based system") does 2. and 3., but in its usual mainline implementations still needs a conventional train detection system.

> it was just switched off because it was broken. That's downright reckless, and it shouldn't be a normal behavior.

The Spanish line in question is actually equipped with conventional colour-light signalling (and the corresponding conventional train protection system) as a fall back, which is perfectly safe, too.

The only critical bit (which by the looks of it unfortunately failed here) is managing an unplanned transition between the two, because for reasons of cost, the fallback signalling utilises much longer block sections than the LZB signalling, so if the LZB fails unannouncedly, you can end up with multiple trains (each inside its own dedicated LZB block section) inside the same line-side signalling block section, so restarting the train needs to be safely managed by getting them out of the accidentally shared block section one at a time.

The problem then becomes avoiding false positives – on multi-track lines, trains on adjacent lines can pass each other as little as 3 to 4 metres away, and within stations and junctions, you can't properly predict a collision without also being aware of the current point positions.

The signalling system has already all the necessary data here, the trains by default none to few of it.

Hence it is usually way more tractable to just improve the reliability and functionality of the signalling system itself and don't bother with complicated technical fallback solutions.

(Things might look differently if you've only got single track lines and no modern signalling system in place – in that case a TCAS-like system might be worth it and not too difficult to implement, especially if you limit its scope to the plain single track line outside of station areas.)

Flying is different – the difference between your positional accuracy and the minimum safe separation between planes is way more favourable, so detection of potential conflicts is much easier.

And – while these days air traffic controllers do usually have computerised aids available to detect impending traffic conflicts, ultimately the system still relies on controllers correctly detecting any conflicts, issuing the correct commands to pilots, and those pilots then correctly executing those commands, too. That's a lot of human in the loop, so the impetus for some fallback safety system (TCAS or whatever) is much stronger.

With trains on the other hand, the default state for any kind of remotely modern signalling (for at least a few decades already, actually) is that the signalling is able to automatically ensure that the route is set correctly, that no conflicting routes are set and that no other trains are occupying the route. Likewise, even without full automated driving it is still possible to ensure that trains are actually following the commands of the signalling.

Hence with railways, the appetite for a completely secondary technical fallback systems to cover outages of the primary signalling system has been much lower, and like I said, it is usally more tractable to try improving the safety and reliability of the primary signalling system. (Though yes, for the fallback case you also need to properly prepare appropriate manual procedures that take into account the increased failure risk of manual operations…)

Trains can safely pass each other within a few metres distance, so GPS by itself is not enough.

> If we could just all stick to UTC in the world...

A very useful property of the current system is that calendar days are aligned with solar days and the change of calender date consequently happens when most of the population is either asleep or otherwise not too fussed about the exact date.

UTC-only (or equivalent "global time" proposals) breaks that for everybody not living near wherever the meridian ends up, which causes a lot of weirdness when a single calendar date can suddenly refer to two completely different solar days and two completely different wake cycles.

Additionally, such a proposal would also break all clock time references in fiction, especially when reading works set abroad or in some unspecified (but still Earth-like) setting, but I guess if you don't care about the calendar date weirdness, you wouldn't care about that, either…

> My preferred solution would be to abandon all time zones and use something like UTC

Which means that

a) textual time references in stories would stop working unless also specifying a location, which would cause a lot of weirdness, especially in fiction

b) perhaps more importantly for day-to-day life, it causes a lot of weirdness around the change of the calendar day and the weekday. It's a rather useful property of the current system that the change of calendar day happens at a time when most people are asleep or otherwise not too fussed about the exact calendar date.

If you completely abolish time zones, that means that for everybody not lucky enough to live near wherever the meridian ends up (which would always be a significant fraction of the world's population, no matter where you'd place the meridian), the change of calendar date would happen during the middle of the waking hours, which causes a lot of weirdness (do public holidays now actually start and stop in the middle of the working day?) and makes date references vastly more cumbersome because a single calendar date can now refer to both solar n in the afternoon/evening and solar date n+1 in the morning.

So you'd have to start using rather awkward double dates for referring to a certain solar day ("the event will take place from the 22/23rd to the 24/25th", "see you on Thursday/Friday" [which isn't the same thing as "see you on Thursday or Friday" today, because that'd become "see you on Thursday/Friday or Friday/Saturday" under the new system properly]), or else develop some convention based on the local solar noon/midnight, which is basically reintroducing time zones through the back door.

The iTunes store has had 1:30 long previews above a certain song length threshold (2:30, if I remember correctly?) for years now.

> which requires just your banking app

Which might not play nice with rooted phones/unlocked bootloaders, either.