EBME Forums Forums Free discussion Free discussion GMT or not ?

the only way it would be possible to have noon with the sun at its zenith would be if each city and town had its own local time. We had to put a stop to all that when the railways were built.

Yes ... but if you lived in Greenwich, you wouldn't want High Noon to be at 1 o'clock, would you?

This is an ageold debate Perhaps your could add something to your MD policies to catch-all?

General Medical devices are not linked to any form of synchronised hospital timekeeping system; as such it is inherent that they will always display some level of inaccuracy or deviation from UTC/Zulu. Medical Devices should therefore always be supported by the use of a synchronised clock or central timekeeping system.

Real time clocks in all non-PC based medical equipment will be set to Greenwich Mean Time (GMT). This will negate the requirement to change them every six months to account for British Summer Time (BST) and remove the uncertainty of what time the clock is set.

Medical device users are permitted to change user configurable clock settings provided they understand that these are for illustrative/indicative purposes only.

Speaking of Time ...

... I notice that Garrith's original post was made ten years ago!

See what I mean?

Hopefully folk won't mind this thread being recalled (it didn't seem right to open a new one for an event that occurs only once in four years).

OK ... it's Leap Day. So here's my question (related to a programming issue) ... if your program was asked to look back a year from now, where would you expect (want, hope) it to jump to (as 29-Feb-11 would represent an error condition):-

1) 28-Feb-11
2) 01-Mar-11

If you wanted to skip back four years, you should get 29-Feb-08 of course. Hope you all see what I'm saying. And I need to get this done today ... else I've have to wait another four years!

[fifty minutes or so later]:- thinking about it a little over a cup of tea, I believe that the logical answer in this case is "01-Mar-11". So I shall arrange things accordingly. When operating with date functions (PM dates past and future in the main) I reckon it's always best to err on the side of "one step forward" rather than back (and I write as one who once spent many, many, hours tracking down a bug - not one of my own [although it could well have been] - whereby hundreds of PM appointments had been "consigned to the dust-bin of time" due to having invalid dates assigned. In the end I found that someone had entered "Closed" dates with values earlier than the "Opened" ones ... and once I spent a few hours remedying that situation, all was well)!

Don't do any planned work on the 29th February is the easiest answer, Use it to catch up on all the jobs you meant to get around to doing during the last four years.
Anyone been proposed to yet?
Robert

That's probably good advice.

In the case in point the user was getting "bad date" responses if s/he tapped in "29-Feb" when calling up a Diary date. So it wasn't really a once every four years problem. Anyway, it's sorted out now:- user taps in "29-Feb" for a non-leap year ... program delivers "01-Mar" (but "29-Feb" if it is a leap year).

By the way, the events I mentioned (about "losing PM's") took place 25 years ago. No wonder I feel so old these days. Anyone else remember KSAM* files? But even back then a decent programmer would (should) have trapped those dates when a closing date was entered at a value less than (before) the opening date. Pretty basic stuff I would have thought.

Greetings to All on the Happy Occasion of Saint David's Day, by the way. The daffodils are out here (just about).

* Key Sequential Access Method

Back to GMT again tonight (where we should always be) ... so that's me re-aligned with the rest of the country again for the next five months or so!

Time for an update, perhaps?

OK guys (the saga continues) ... what happened this year?