On Mon, Mar 30, 2015 at 4:35 PM, Lester Caine <lester@xxxxxxxxxxx> wrote: > On 30/03/15 20:13, Richard wrote: >> >> >> ------------ Original Message ------------ >>> Date: Monday, March 30, 2015 20:04:56 +0100 >>> From: Lester Caine <lester@xxxxxxxxxxx> >>> >>> 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. >>> >> >> You can get the information you're after with "zdump -v" of the >> zoneinfo file for a timezone, e.g., >> >> zdump -v GB | grep 2015 >> >> GB Sun Mar 29 00:59:59 2015 UTC = Sun Mar 29 00:59:59 2015 GMT >> isdst=0 gmtoff=0 >> GB Sun Mar 29 01:00:00 2015 UTC = Sun Mar 29 02:00:00 2015 BST >> isdst=1 gmtoff=3600 >> GB Sun Oct 25 00:59:59 2015 UTC = Sun Oct 25 01:59:59 2015 BST >> isdst=1 gmtoff=3600 >> GB Sun Oct 25 01:00:00 2015 UTC = Sun Oct 25 01:00:00 2015 GMT >> isdst=0 gmtoff=0 >> >> how you deal with it from there is up to you -- there are many >> options I would think, including loading it into a DB that you >> check. The system TZ files do change from time to time, as the local >> rules change, so you'd need to manage for that. > > Or just use a DateTimeZone object? > Larry's original question was about checking if a time was 'within the > DST switchover' but that would not help. What is needed is simply the > offset for each time in the raw data ... that is if Larry simply has raw > times as the data. Thanks for the replies everyone. Turns out I have to deal with this in the database because all this is done in stored procs. The raw times are in local time. I am going to change them to UTC and then convert them to local time for output. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
