This week's Torah Portion is Tzav - where we learn about the Mitzvah to keep the fire on the Altar burning continuously. 24/7 as we would say.
The Mishna teaches us that the Cohanim - the priests in charge of the Temple service - were on duty from before dawn until way past sunset. During the festivals they sometimes started around midnight.
We all understand that live systems have to be available 24/7, or at least 24/6 depending on the user base.
To ensure round-the clock- coverage, the day is split into 3 or 4 shifts, often in appropriate time zones.
But, when deadlines loom, for some reason it's assumed that the same people can work around the clock. Or, at the very least, remain late and function as usual the next day.
My first such experience was in the 90's. We were preparing the Gold Disk; the Master CD that would be shipped to Ireland from which other CDs would be copied, put into boxes with their user manuals and shipped back to us. (All this with dinosaurs threatening to stomp through the factory.)
It had to be ready first thing the next morning, or else we were doomed.
We did an all-nighter. As the person who did the setups, I would get the latest build from engineering, run the setup scripts (which only included 2 manual steps) and inform QA that it was ready to be tested.
We were "ready to ship" before the sun rose. We were elated.
Until 2 days later. The first day, if any of us came (back) to work, it was after lunch time. Rare are those who can function properly after missing a night's sleep.
The next day, we were back, ready to celebrate properly, but QA started finding bugs. As Time went on, more and more issues were found and fixed.
End of story? We received a shipment of shrink-wrapped software that ended up as land-fill. We eventually prepared another Gold Disk after thorough testing - and we received a sellable shipment of shrink-wrapped software a few weeks behind schedule.
Since then I have been opposed to meeting deadlines by working after-hours.
How? You can find a clue by reading this question of mine on StackExchange's Project Management network, for example.