Re: Telling if a given datetime is within the DST switchover
| From: | Larry Martell | Date: | Tue, 31 Mar 2015 03:54:22 +0000 |
| Subject: | Re: Telling if a given datetime is within the DST switchover | ||
| References: | 1 2 3 4 5 6 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-324742@lists.php.net to get a copy of this message | ||
On Mon, Mar 30, 2015 at 4:35 PM, Lester Caine <lester@lsces.co.uk> wrote:
> On 30/03/15 20:13, Richard wrote:
>>
>>
>> ------------ Original Message ------------
>>> Date: Monday, March 30, 2015 20:04:56 +0100
>>> From: Lester Caine <lester@lsces.co.uk>
>>>
>>> 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.