How Does the Military, Police, Etc. Notate the "second" 1:30 am when we "fall back"?

November 6, 2007 8:25 AM

How do places where precise timekeeping is essential handle the repeat of an hour when we go off Daylight Savings Time?

There are certain professions in which I imagine very specific denotation of time is particularly important — hospital, military, first-responders (police, fire, ambulance), specialized equipment, etc.

"Spring forward" is probably not a problem, because it "removes" an hour — 2:00 jumps to 3:00. But in the fall, an hour is repeated — that's what I'm curious about.

In these venues, how do they handle properly distinguishing the first 1:30 am from the second 1:30 am? Is it done informally (i.e. Joe the ambulance driver writes down "1:30 am (second time 'round)" in his log while Frank the ambulance driver writes down "1:30 am post-DST" and George the ambulance driver forgets and just writes down "1:30 am"? Or is there a generalized standard in the field.

posted by WCityMike to grab bag (11 comments total)

Good question. I was going to just say "UMT" or some such. Military applications often use the universal time because of being so spread out across the world. Immunity from daylight savings is just a side effect of this. But hospitals and police departments are another matter entirely.
posted by TeatimeGrommit at 8:29 AM on November 6, 2007

Well from a technical standpoint, there would be a 1:30am ED(aylight)T and a 1:30 ES(standard)T but I rarely see people be that thoughful and careful with the timezones (I know I am not as attentive to that detail as one should).
posted by mmascolino at 8:36 AM on November 6, 2007

Teatime is right about the military: they (along with other wide-scale applications such as aeronautical and maritime agencies) abide by whatever subset of 24-hour time is appropriate for their use: Z (Zulu Time), UTC (Coordinated Universal Time), GMT (Greenwich Mean Time), etc.

Regarding local municipalities, it certainly seems to have caused an issue or two along the way; this study indicates that "timepieces used in critical care are highly variable and inaccurate," while also noting that "UTC is not currently the reference standard for time at this institution." I've certainly never been in a hospital which chose UTC over local time.
posted by mykescipark at 8:52 AM on November 6, 2007

If you are writing your dates in ISO 8601 then you don't have an issue since the timezone does not include any DST information. So you would write (in the case of London) GMT prior to the summer time switch and then BST afterwards. Or you use offsets from UTC. No ambiguity that way.

If you are using locative names like Europe/London or US/Eastern for your timezones then you will have to take into account DST which is obviously ambiguous during the DST period.

I would expect in places where it really matters people get used to running entirely on UTC or some constant offset from that.
posted by public at 9:00 AM on November 6, 2007

I'm in the military, and we normally keep our logs in local time. We treat daylight savings shifts the same as when we cross time zones. Each time zone has a designator letter, as shown on this obnoxiously colored chart at the bottom.

In the Seattle area, we're in -8(Uniform) time right now, so I'd write 0900 on my log, or if that were ambiguous, I'd write 0900U.

Before we shifted to/from DST (I can't remember which is which), we were the -7(Tango) time zone, so I'd write 0900T. On days in which we shifted time zones causing an hour to apparently repeat, for the first hour I would write something at say, 0130T, then there would be a log entry remark at 0200T that clocks were shifted to Uniform time. The next hour would be 0100U-0159U. After that, I'd start dropping the time zone again, because it's non-ambiguous.

Computers are just kept on zulu time, and the interface translates to and from local time. I only have to select a different time zone.
posted by ctmf at 9:08 AM on November 6, 2007 [1 favorite]

One method (with computers) is to make the hour take two hours ... so a second ticks by every two seconds ... and after "one hour" go back to normal as the time is aligned again ... and all your "consecutive time stamps" are still consecutative and consistent ... I seem to recall that Novel Netware 4 used a similar system to this (as their timestamps on the NDS were rather important) and it worked well.
posted by jannw at 9:21 AM on November 6, 2007

sorry ... mistake in previous post - to clarify ... this is what happened if you changed the "core internal clock" on netware ... DST changes were more like what CTMF said above
posted by jannw at 9:23 AM on November 6, 2007

I don't think there's a standard way of logging when you cross the date line, though. I think when we've done it, I've just appended something to the second day's date, like 06A November.

I do remember pulling my hair out looking for a missing log (months later) that turned out to have been a day lost due to crossing the date line the other direction. And I've known guys whose birthday got skipped.
posted by ctmf at 9:41 AM on November 6, 2007

I work with deep space spacecraft and we have antenna stations all over the world. Timing is pretty critical as you might expect. The way we handle it is by having everyone use UTC. We start shifts based on local time but everything else is recorded and timed by UTC. There aren't any windows where I work so it's a little disorienting to walk outside at 3 in the morning and have it be 7 in the evening local time. Really screwed with my sense of time for a while.
posted by MasterShake at 12:25 PM on November 6, 2007

Well, in the world of computers you'd use something like UTC. Then you'd calculate the local time zone when you want to display it. So if you have internet time/NTP enabled your computer asks the time server for UTC time, stores in internally, and then displays it as you like.

If you use windows at work there's a good chance youre on a domain. To authenticate to the domain the protocol checks to make sure the time on the client and the server are within 5 minutes of each other. So you can set your computer time to something like 8 hours in the future, and then reboot and you'll get an error because the time is off. But if you just change the timezone to something far away or edit the registry to change when DST happens, you'll still be able to login because the UTC is still correct.
posted by damn dirty ape at 1:06 PM on November 6, 2007

At 0110 GMT I was logged into a radio station's automation system from Cork (it's in an undisclosed location in the UK), reloading the running order for Sunday and telling it to start from scratch. This was done by echoing strings at a numbered port over ssh and waiting ten seconds to hear if I'd had any effect because my only monitor was the public webcast.

This because the 2am top-of-hour news and ID sequence had already fired at 2am summer time.

A song crossfaded out about a minute early, and the song which had played at 00:03 played again at about twenty to three. That station played five or six songs again, and at 10 seconds to 0200GMT, the 2am events were run again and the station picked up where it left off.

Radio, generally, handles the autumn clock change either badly or manually-with-someone-babysitting-the-station. Even when there's a defined method for making these things work unattended, I don't know anybody who trusts their kit suppliers enough to assume a once-yearly event has been coded properly. But if we're all being honest with each other, almost nobody's listening and it's not exactly life and death.

Once the 2am news by satellite ended, I went to bed.

[Oh, and all this happens the week before over here.]
posted by genghis at 3:23 PM on November 6, 2007 [1 favorite]