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"
Related
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).
I am using FileAPI to get the HTTP-header Last-Modified time of a file, which is returning the following string:
Fri Oct 25 2013 12:04:10 GMT+0100 (GMT Daylight Time)
This is then posted to PHP and I need it converted to something sensible, preferably a timestamp. Before you suggest it, strtotime() returns FALSE.
Can't seem to find any answer to this anywhere.
Fortunately since 5.3.0 there is DateTime::createFromFormat(). Although it cannot parse the trailing information it is at least able to ignore it using the + specifier. You don't need that information in order to create a timestamp as you already have the, machine parsable, GMT+0100.
Example:
$str = "Fri Oct 25 2013 12:04:10 GMT+0100 (GMT Daylight Time)";
$fmt = 'D M d Y H:i:s O+';
$datetime = DateTime::createFromFormat($fmt, $str);
echo $datetime->getTimestamp();
Output:
1382699050
Well, if the problem is the string inside the parentheses, you could substring it to the first one and use strtotime as #Marcell suggested in the comments.
I'm not sure that this is a bug since after searching I can't find any duplicate experiences- however, this one has me stumped.
While in the midst of a (rather painful) script that is intended to take a bunch of freetext records and convert them to useful date records, my trusty friend strtotime() seems to have let me down.
For testing purposes, I boiled the code down to this:
<?=date('Y', strtotime("1999"));?>
Output shows: 1999
<?=date('Y', strtotime("1981"));?>
Output shows: 1981
<?=date('Y', strtotime("2001"));?>
Output shows: 2012
<?=date('Y', strtotime("2021"));?>
Output shows: 2012
Everything seems fine until the input exceeds "1999"- From that point on, every year before and after the current one returns the current year (2012)
Any input is much appreciated.
As per PHP's date/time format docs:
The "Year (and just the year)" format only works if a time string has already been found -- otherwise this format is recognised as HH MM.
(2nd last note on the page).
Try prefixing the years with Jan 1,.
For example:
<?=date('Y', strtotime("Jan 1, 2021"));?> outputs 2021 as expected.
I'm supposing this is because certain years can be incorrectly parsed as month/day pairs, such as "2012" being interpreted as "December 20th of the current year".
If you want proof for yourself, try changing the date format to r:
<?=date('r', strtotime('2001'));?> gives Thu, 23 Feb 2012 20:01:00
The problem is, that it is parsed as time, what you can see if you use date('c') instead of date('Y');.
php > var_dump(date('c', strtotime("2001")));
string(25) "2012-02-23T20:01:00+01:00"
You should pass the value unambiguous for example 2012-01-01.
Another solution is to use a function, that allows to specify the format of the given input, like strptime(), or DateTime::createFromFormat()
php > echo DateTime::createFromFormat('Y', '2001')->format('c');
2001-02-23T22:29:56+01:00
Use this:
echo date('Y', strtotime("1/1/2001"));
echo date('Y', strtotime("1/1/2021"));
Using 4 digits as date can be interpreted as time, you should use a more specific format to make sure the function works as you expect it.
So 2021 is 20:21 (24h format) of 2012
$plaintext = '2004'; //'2004-11','2004-5','2004-5-1','2004/5-1','2004/08/10'
echo date('Y', strtotime(
(strlen($plaintext)==10?$plaintext:
(strlen($plaintext)==7? str_replace('-','/',$plaintext).'/01':
(strlen($plaintext)==4?$plaintext.'/01/01':$plaintext)
)
)));
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
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.