SpaceX are doing what an inflight abort of the Dragon 2 spacecraft this Saturday. To make sure Dragon 2 can keep astronauts alive should the ascent phase go badly, they are going to tell it to go into inflight abort mode at MaxQ (when atmospheric pressure is highest) and they hope it will use its rockets to clear off to a safe distance, deploy its parachutes, and splash down safely. The 1st stage won't be protected from the atmospheric forces by Dragon 2 so it will disintegrate with a side order of exploding. Worst case is they scrub (launching early on a Saturday without a launch window, so easy to delay) but under all other scenarios we should get to see something blow up.
In case you're wondering why I make this comment, consider compilers and the question of source languages and target languages. I remember when for every combination of SRC/TGT there was a different compiler. As the number of source languages grew, and the number of target platforms grew, so the number of compilers grew even faster.
The obvious solution (although there are problems) is to create a single, intermediate language ... let's call it BANDJI. Then for every source language we write one front-end, for every target language/platform we write one back-end, and the combinatorial explosion is tamed.
Of course, really properly new languages can't always be mapped onto BANDJI, so this doesn't always work as easily as one might hope. Even so, it limits the combinatorial explosion of required work.
What does this have to to with my original comment about time zones?
If you announce something in your local time zone, you then require that the reader knows how to convert that time zone to their local time. So every reader has to know how to convert every timezone. Worse, they will also need to know when and if the different timezones change for Summer time, and by how much.
If, instead, you publish/specify information in just UTC, then everyone only needs to know exactly one conversion - their own from (and to) UTC.
So it's worth considering publishing your times in UTC, possibly as well as local time to cover the majority case. But if you have any aspirations to being understood by people outside your immediate geographical area, maybe it's worth a thought.
2 comments
[ 1.0 ms ] story [ 13.0 ms ] threadSpaceX are doing what an inflight abort of the Dragon 2 spacecraft this Saturday. To make sure Dragon 2 can keep astronauts alive should the ascent phase go badly, they are going to tell it to go into inflight abort mode at MaxQ (when atmospheric pressure is highest) and they hope it will use its rockets to clear off to a safe distance, deploy its parachutes, and splash down safely. The 1st stage won't be protected from the atmospheric forces by Dragon 2 so it will disintegrate with a side order of exploding. Worst case is they scrub (launching early on a Saturday without a launch window, so easy to delay) but under all other scenarios we should get to see something blow up.
* Test is scheduled for 2020/01/18 08:00 EST
* That is 2020/01/18 13:00 UTC
In case you're wondering why I make this comment, consider compilers and the question of source languages and target languages. I remember when for every combination of SRC/TGT there was a different compiler. As the number of source languages grew, and the number of target platforms grew, so the number of compilers grew even faster.
The obvious solution (although there are problems) is to create a single, intermediate language ... let's call it BANDJI. Then for every source language we write one front-end, for every target language/platform we write one back-end, and the combinatorial explosion is tamed.
Of course, really properly new languages can't always be mapped onto BANDJI, so this doesn't always work as easily as one might hope. Even so, it limits the combinatorial explosion of required work.
What does this have to to with my original comment about time zones?
If you announce something in your local time zone, you then require that the reader knows how to convert that time zone to their local time. So every reader has to know how to convert every timezone. Worse, they will also need to know when and if the different timezones change for Summer time, and by how much.
If, instead, you publish/specify information in just UTC, then everyone only needs to know exactly one conversion - their own from (and to) UTC.
So it's worth considering publishing your times in UTC, possibly as well as local time to cover the majority case. But if you have any aspirations to being understood by people outside your immediate geographical area, maybe it's worth a thought.