This is what to do in Java. Just update using PHP DateTimeZone::getOffset Create two dates: one in June, one in January. Compare their getTimezoneOffset() values. if January offset > June offset, client is in northern hemisphere if January offset < June offset, client is in southern hemisphere if no difference, client timezone does not observe DST Now check getTimezoneOffset() of the current date. if equal to June, northern hemisphere, then current timezone is DST (+1 hour) if equal to January, southern hemisphere, then current timezone is DST (+1 hour) On Mar 30, 2015, at 11:51 AM, Ryan Pallas <derokorian@xxxxxxxxx> wrote: > On Mon, Mar 30, 2015 at 9:41 AM, Larry Martell <larry@xxxxxxxxxxxxxxxxxxxxx> > wrote: > >> On Mon, Mar 30, 2015 at 11:36 AM, Lester Caine <lester@xxxxxxxxxxx> wrote: >>> On 30/03/15 16:20, 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. >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > Sounds like your only solution may be to convert to UTC to do the logic of > checking for gaps.
