On 30/03/15 16:41, Larry Martell wrote: >>> The use case is that I have a server uptime reporting script and it >>> >> uses a database of times that the server was able to be pinged. If >>> >> there is no entry for a period it indicated the server was down. So on >>> >> March 29, running in London, it found no entries from 1am to 2am and >>> >> it reported the server was down for an hour, when in fact the period >>> >> from 1am to 2am did not exist because of the switch to summer time. >> > >> > If you are logging ANYTHING other than UTC then your reporting system is >> > the problem. You DISPLAY times using the local time, and log everything >> > using a clean UTC time. > I 100% agree with you, but this client does not do that. I have told > them they should, but they did not want to change. As Ryan says ... convert to UTC to do the check, but personally I'd be looking at why 1amGMT and 2amBST is reporting 2 hours rather than 1 hour. I've been through this many years ago now with clients who simply recorded the 'time'. Railway timetables never used to run over night at that time, but when they started, timetables got interesting ;) When the underlying process was switched to UTC and all of the hacks to get the correct running times were removed the objections were also removed. I presume that all you get from the database is '1am' or '2am', so you just need to add the missing offset information from the calendar. So you have 1amGMT and 2amBST to compare. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
