Timestamp comparison in MySQL and PHP ( UTC, +0000, Timezones ) - php

I'm trying to determine whether a string that represents the date and time, given in a JSON Twitter feed is within a range of timestamp columns in MySQL.
Here's the example string:
'Sat, 31 Oct 2009 23:48:37 +0000',
The +0000 according to the API ( created_at ) indicates it is indeed UTC. Now, I'm using strtotime and date just to confirm the time. With:
$t = 'Sat, 31 Oct 2009 23:48:37 +0000';
$timestamp = strtotime($t);
echo date('M d Y H:m:s', $timestamp);
I get Oct 31 2009 19:10:37. If I remove the +0000 I get Oct 31 2009 23:10:37. So the difference between having +0000 and not having it is 4 hours. I'm guessing because of my local timezone ( Maryland, USA = America/New_York ) and that differing from the UTC obviously.
I'm not quite sure if I should be stripping the +0000 or using it when trying to determine if this timestamp is within the range of the two timestamps stored in my database, which are 2009-10-30 23:16:38 and 2009-11-25 12:00:00. I feel silly and a bit confused now, when I populated these timestamps the YYYY-MM-DD H:M:S came from a Javascript date time picker, an example format is 10/31/2009 11:40 am and I use STR_TO_DATE like so:
STR_TO_DATE("10/31/2009 11:40 am", "%m/%d/%Y %l:%i %p")'),
Should I leave the +0000 or strip it? Mentally taps out

You should of course leave the timezone information in, provided you're also properly setting the server timezone. Otherwise what's the point, all your time comparisons will be 4 hours off. :o)
To compare the time you should leave it as UNIX timestamp, i.e. the result of strtotime.
$twitterTS = strtotime('Sat, 31 Oct 2009 23:48:37 +0000');
$localStartTS = strtotime('Sat, 31 Oct 2009 19:00:00'); // timezone is -0400 implicitly
$localEndTS = strtotime('Sat, 31 Oct 2009 20:00:00');
if ($localStartTS <= $twitterTS && $twitterTS <= $localEndTS) {
// twitter timestamp is within range
}
To clarify: Before comparing times from different timezones, make sure they're all converted to the same timezone. Comparing London time 20:00 to New York time 20:00 without timezone information will yield incorrect results. strtotime will convert all times to your local timezone; if timezone information is present in the input it will honor it and convert the time appropriately, otherwise it'll assume the time is already localized. If all the times in your database are local, you should absolutely make sure to localize all timestamps you want to compare against them.
An alternative strategy would be to always convert all times to UTC before storing or comparing them.
Take your pick, just do so consistently.

In PHP you can simply use the substring function to break down the json twitter time into its components as so
//'Sat, 31 Oct 2009 23:48:37 +0000'
$hour = substring($jsontime,18,2);
$minute = substring($jsontime,22,2);
...
$phpDatetime mktime($hour,$minute,$second,$month,$day,$year);
From there I think you already have it. Dont' forget to adjust for GMT differences.

Related

Why format DATE_RFC7231 ignores timezones?

I was playing recently with date formats in PHP and the hardcoded GMT timezone in format DATE_RFC7231 puzzles me.
I have example below of two the same dates formatted differently, however even if the input is the same, the output differs because of the timezone difference! So, the hours are not casted proportionaly to the given timezone and it displays confusing results.
echo DateTime::createFromFormat(DATE_ATOM, '2023-02-15T06:44:41+08:00')->format(DATE_ATOM); //2023-02-15T06:44:41+08:00
echo DateTime::createFromFormat(DATE_ATOM, '2023-02-15T06:44:41+08:00')->format(DATE_RFC7231); //Wed, 15 Feb 2023 06:44:41 GMT
Is this intentional to show always GMT despite the timezone set to the Datetime object? Or am I missing something essential about the format RFC7231?
Actually, now that I look at it it's generating 06:44:41+08:00 and 06:44:41 GMT from the same input. Which is somewhat wrong-ish.
What is actually wrong, though, is thinking that a format string would perform a transformation on the DateTime object. The constant DATE_RFC7231 is simply the string "D, d M Y H:i:s \G\M\T" which hard-codes the string GMT into the format.
The solution is to set the timezone to GMT before formatting, as below:
var_dump(
DateTime::createFromFormat(DATE_ATOM, '2023-02-15T06:44:41+08:00')->
setTimezone(new DateTimezone('GMT'))->
format(DATE_RFC7231)
);
Output:
string(29) "Tue, 14 Feb 2023 22:44:41 GMT"

Using strtotime() PHP and revert back trough gmdate() is not returning same date

I have a string $StartDate = "2015-09-23" (should be like yyyy-mm-dd).
Than I make $UdtStart= strtotime($StartDate) that returns 1442980800;
Well if I go to this link it return back "Wed, 23 Sep 2015 04:00:00 +0000".
First, why do we have 04:00:00 added?
Than, if I do this $back=gmdate("Y-m-d H:i:s", ($UdtStart)); I will have "2015-09-26 04:00:00".
What am I missing?
$UdtStart= strtotime($StartDate);
$back=gmdate("Y-m-d H:i:s", ($UdtStart));
Wed, 23 Sep 2015 04:00:00 +0000
Note that +0000 on the end, that means the time is UTC. As per the PHP strtotime() doco:
Each parameter of this function uses the default time zone unless a time zone is specified in that parameter.
The gmdate is for Greenwich Mean Time (and really should be called something like utcdate nowadays), so you're asking for the data in a different foramt from what you gave it.
I'd be willing to bet money that you're in a timezone four hours removed from UTC, which is why you're seeing that.
If you want local time, use date() rather than gmdate(). The gmdate doco states:
Identical to the date() function except that the time returned is Greenwich Mean Time (GMT).

strtotime fails on pubDates from RSS feeds?

Example:
print strtotime('Sat, 03 Nov 2012 20:17:12 0000');
prints nothing :(
And the date string appears to be correct..
it's:
day name, day month name year hour:min:sec timezone
Valid formats are explained in Date and Time Formats.
Consider using DateTime objects, and the createFromFormat() method
I get it you want to add a timezone correction. But the timezone requires a sign.
print strtotime('Sat, 03 Nov 2012 20:17:12 +0000');
This will work
print strtotime('03 Nov 2012 20:17:12');
Output: 1351988232
This works perfectly. You should remove the 0000 and the day (Sat)

PHP strtotime EST back and forth conversion

For EST time, I've set:
date_default_timezone_set("America/New_York");
As the page loads, I'm getting EST time via:
$time = time();
The problem is when I convert strings back and forth between timestamps and datetime format:
10/31/2012 7:30pm 1351729800 | 10/31/2012, 8:30 pm
11/2/2012 7:30pm 1351902600 | 11/02/2012, 8:30 pm
11/3/2012 8:00pm 1351990800 | 11/03/2012, 9:00 pm
11/7/2012 8:00pm 1352336400 | 11/07/2012, 8:00 pm
11/9/2012 8:00pm 1352509200 | 11/09/2012, 8:00 pm
11/10/2012 8:00pm 1352595600 | 11/10/2012, 8:00 pm
I'm expecting these date & times to be the same.
The first section (before the "|") is simply strings, such as "10/31/2012 7:30pm" and the strtotime("10/31/2012 7:30pm EST").
The section (after the "|") is date() of the previous strtotime() value.
What can I do to convert from string to time (strtotime) and double check that the date format returned is the same as the string input?
Thanks
I'd say that this is because currently New York is on daylight savings time - EDT rather than EST. This affects things like so:
date_default_timezone_set("America/New_York");
strtotime("10/31/2012 7:30pm"); // translates to "Wed, 31 Oct 2012 19:30:00 -0400"
strtotime("10/31/2012 7:30pm EDT"); // translates to "Wed, 31 Oct 2012 19:30:00 -0400"
strtotime("10/31/2012 7:30pm EST"); // translates to "Wed, 31 Oct 2012 20:30:00 -0400"
The quick fix is probably to not add the timezone to the string, strtotime() will use the correct default timezone you set.
You can be a bit more exact about how your date is being parsed by using the DateTime createFromFormat function:
$date = DateTime::createFromFormat('m/d/Y g:ia', "10/31/2012 7:30pm");
echo $date->format('U');
Alternatively if you wait until November the problem will resolve itself :-)
Some times you need to set and forget a time in a PHP script and moving to a new server could change your hard work. if you are doing date with string to time for example add your time zone code to your string like New Yourk wiht daylight savings time: 'EDT'
echo date('g:i a',strtotime('10:59 EDT'));// 10:59 am
or if you want to extract the amount of seconds an specific time has, lets say 10:59pm, use something like:
echo gmdate('g:i a',strtotime('January 1 1970 10:59pm GMT'));//82740 seconds
//converted to 10:59pm
the latter will give you (12+10 hours(*60) and 59 minutes)*60 in seconds, and the gmdate function will echo the GMT time from what ever seconds you pass to the function.. if you try date instead you will, most likely, not get 10:59 unless you live in the GMT time zone (Greenwich Mean Time).
This time zone stuff can get very confusing, so be very careful and mess around with it when having a very specific plan..like converting someones time to yours, etc.

Using DateTime in PHP, generating bad unix epoch time from $foo->format('U')

I can't seem to get the correct Unix epoch time out of this PHP DateTime object.
$startingDateTime = "2005/08/15 1:52:01 am";
$foo = new DateTime($startingDateTime, new DateTimeZone("America/New_York"));
echo $foo->format('U');
which gives
1124085121
Which is Mon, 15 Aug 2005 00:52:01 GMT -500 (according to EPOCH CONVERTER) but that's incorrect by an hour.
It SHOULD be 1124088721 and spit back at me as Mon, 15 Aug 2005 01:52:01 GMT -500
Any help would be appreciated.
This is likely a DST problem with epoch converter. I used another converter to UTC time and then to America/New_York. I got the right answer given timestamp=1124085121

Categories