Hi i am working on facebook Graph API where i need all the posts information of a group. So I did it and saw [created_date'] => '2013-01-25T00:11:02+0000' what does this date and time represent i mean i know 2013-01-25 is date and 00:11:02 is time but what does T and +0000 represent.
BTW where is the server of facebook. Which timestamp should i use to match facebook time?
Thank you.
T = TIME and the +0000 is timezone offset. Facebook uses localized timezones. You can request a Unix timestamp instead of the string by adding the parameter: date_format=U to your graph API call.
Please see this link for more information.
The date format is called ISO 8601. The letter T is used to separate date and time unambiguously and +0000 is used to signify the timezone offset, in this case GMT or UTC.
That said, you generally don't need to worry so much about the actual contents; rather you should know how to work with them. To use such a date, you can use strtotime() to convert it into a time-stamp:
$ts = strtotime('2013-01-25T00:11:02+0000');
To convert the time-stamp back into a string representation, you can simply use gmdate() with the predefined date constant DATE_ISO8601:
echo gmdate(DATE_ISO8601, $ts);
Alternatively, using DateTime:
// import date
$d = DateTime::createFromFormat(DateTime::ISO8601, '2013-01-25T00:11:02+0000');
// export date
echo $dd->format(DateTime::ISO8601), PHP_EOL;
This is a standard format, specifically ISO 8601.
As much as I don't like linking to it, http://www.w3schools.com/schema/schema_dtypes_date.asp does have a good "human-understandable" explanation:
The dateTime is specified in the following form "YYYY-MM-DDThh:mm:ss"
where:
YYYY indicates the year
MM indicates the month
DD indicates the day
T indicates the start of the required time section
hh indicates the hour
mm indicates the minute
ss indicates the second
To specify a time zone, you can either enter a dateTime in UTC time by
adding a "Z" behind the time - like this:
2002-05-30T09:30:10Z
or you can specify an offset from the UTC time by adding a positive or
negative time behind the time - like this:
2002-05-30T09:30:10-06:00
or
2002-05-30T09:30:10+06:00
Therefore, in your case the +0000 indicates a time offset of 0 from UTC.
Related
Anyone can explain to me in which format are these DateTime strings from OpenWeatherMap API and how to work with them in order to:
Just see the time (Greenwich +1)
sun rise="2019-01-28T06:31:03" set="2019-01-28T16:14:39"
View the Date & Time (Greenwich +1)
lastupdate value="2019-01-28T11:20:00"
Those dates are in ISO 8601
The examples you actually have do NOT contain any TimeZone information so they could be any timezone..
If you work with datetime offsets (that include time zone information) you would typically see something like this
2008-09-15T15:53:00+05:00
The reasone it is formatted in ISO 8601 is so that the date time picker (that is the actual format you use for the value) on your HTML page knows how to interpret the time into your local (machine clock configured time)
Typically if using UTC you will have a date time that looks like
2008-09-15T15:53:00Z
Which is Zulu Time
And as i mentioned already if it does not have any of those it is assumed local time at server that generated it.
Thanks, I was able to convert them by using concatenated date and strtotime functions.
date('H.i',strtotime($sunset_time));
The local time on the server is Greenwich, whereas I would need to add +1 for my time zone (Europe/Rome).
In the end I was able to add +1 hour like this:
date('H.i', strtotime($sunset_time) + 60*60);
Is this a correct way?
Why
echo date('c');
not equal with
$datetime = new DateTime();
echo $datetime->format(DateTime::ISO8601);
The result:
2016-07-07T21:18:22+03:00
2016-07-07T21:18:22+0300
Both must give current time in ISO8601 format. In Wikipedia right format is 2016-07-07T21:18:22+03:00 but some banks use 2016-07-07T21:18:22+0300 format in API. Why?
2016-07-07T21:18:22+03:00
Is the correct ISO 8601:2004 representation.
2016-07-07T21:18:22+0300
Is incorrect, the zone designator may not be in the basic format when the date and time of day is in the extended format.
ISO 8601:2004 4.3 Date and time of day:
[...] the expression shall either be completely in basic format, in
which case the minimum number of separators necessary for the required
expression is used, or completely in extended format, in which case
additional separators shall be used [...]
Update 1:
ISO 8601 specifies three differerent date representations: calendar, ordinal and week dates. Theese can be formatted in either basic format (minimum number of seperators) or extended format (extension of the basic format that includes additional separators). ISO 8601 requires that the resulting expression is either consistently in basic format or consistently in extended format.
Combination of calendar date and time of day in local time with difference from UTC:
2016-07-07T21:18:22+03:00 (extended format)
20160707T211822+0300 (basic format)
Combination of ordinal date and time of day in local time with difference from UTC:
2016-189T21:18:22+03:00 (extended format)
2016189T211822+0300 (basic format)
Combination of week date and time of day in local time with difference from UTC:
2016-W27-4T21:18:22+03:00 (extended format)
2016W274T211822+0300 (basic format)
All of the above representations represent the same date and time of day in local time with difference from UTC (and instant). If an API documents that it accepts an ISO 8601 date with time of day and a zone designator (aka known as a complete representation), it should accept all of the above representations to be compliant with ISO 8601.
Update 2:
Most bugs i have encountered stem from using strftime() to output an ISO 8601 date and time of day in local time with difference from UTC in extended format. The standard strftime() can only output compliant representations in basic format due to the limitations in the z conversion specifier:
Combination of calendar date and time of day in local time with difference from UTC:
Format: Example:
%Y%m%dT%H%M%S%z 20160707T211822+0300
Combination of ordinal date and time of day in local time with difference from UTC:
Basic format: Example:
%Y%jT%H%M%S%z 2016189T211822+0300
Combination of week date and time of day in local time with difference from UTC:
Basic format: Example:
%GW%V%uT%H%M%S%z 2016W274T211822+0300
The GNU strftime implementation supports a : flag between the percent and the z conversion specifier to specify that the zone designator should be formated in extended format:
Combination of calendar date and time of day in local time with difference from UTC:
Format: Example:
%Y-%m-%dT%H:%M:%S%:z 2016-07-07T21:18:22+03:00
Combination of ordinal date and time of day in local time with difference from UTC:
Format: Example:
%Y-%jT%H:%M:%S%:z 2016-189T21:18:22+03:00
Combination of week date and time of day in local time with difference from UTC:
Format: Example:
%G-W%V-%uT%H:%M:%S%:z 2016-W27-4T21:18:22+03:00
Still PHP does not interpret ISO8601 correctly when milliseconds are given, even with DateTime::ATOM.
$d=DateTime::createFromFormat(DateTime::ATOM,"2018-01-10T01:00:00.000Z");
// null
or using Carbon:
echo Carbon\Carbon::createFromFormat(Carbon\Carbon::ATOM,"2018-01-10T01:00:00.000Z","UTC");
// InvalidArgumentException with message 'The timezone could not be found in the database'
The best way is to let Carbon or datetime figure it out itself:
$d = new Carbon\Carbon("2018-01-10T01:00:00.000Z");
// -> 2018-01-10 01:00:00
$d = new Carbon\Carbon("2018-01-10T01:00:00Z");
// -> 2018-01-10 01:00:00
I have two date:
2014-12-01T12:05:59Z //dont know which format
And
2014-12-01T03:59:00-08:00 //i'll get it from date("c") function in php (ISO 8601).
So, I don't know what is the different in this date's?
And how to convert date in 2014-12-01T12:05:59Z this formate in php?
[UPDATE]
I want to get current timestamps in in 2014-12-01T12:05:59Z this date formate.
It's the ISO 8601 format and both time zone variants are allowed and must be expected. -08:00 means 8 hours behind UTC, Z means UTC and is a shortcut for +00:00.
Both the dates you have mentioned are dates with timezone. The only difference is that the first date has 'z' at the end which is a Zone Designator for UTC and the later date is suffixed with timezone offset, which is generally represented as "HH:MM". Practically, both dates are same and both the representations are correct.
The 'z' suffixed representation is generally accepted xml standard for timestamp in API payloads.
Looking at your requirements, since your API provider needs the date with Zone Designator, they must be calculating time in UTC.
I will suggest changing your timezone to UTC first using
date_default_timezone_set('UTC');
and then use this expression to get required timestamp
date('Y-m-d\TH:i:s\Z', time());
This way you are saved from the timezone conflict and you will also be able to send the required date to the API.
date_default_timezone_set('UTC');
echo gmdate('Y-m-d\TH:i:s\Z');
Check the link. You will get the difference as well.
I have dates in my database in local British times (i.e. GMT in the winter and BST in the summer). I want to convert them to DATE_ICAL for displaying into iCalendar format. I have tried both the following.
date(DATE_ICAL, strtotime($row['FixtureDate']);
date(DATE_ICAL, strtotime($row['FixtureDate'].' UTC');
My first date for example is 12:45 BST. If I use the first statement I get 20140809T124500Z and the second I get 20140809T134500Z. Neither shows the right date in Google.
The second is obviously wrong because my time is not a UTC time, I think I need to convert my time to a UTC time as that's what DATE_ICAL wants? But how do I do that?
My server is British. I only care about British times and British users.
Finally figured it out, I needed to use GMDATE not DATE with ICAL format
define('DATE_ICAL', 'Ymd\THis\Z');
GMDATE(DATE_ICAL, strtotime($row['FixtureDate']));
What's the standard (or some kind of iso-conform thing) format to display date (year, month, day) and time (Hours minutes and seconds) together as an result of an API Request? Or should a timestamp be returned in this case?
Use ISO8601 format. And use UTC timezone always. Its the standard by ISO and should be parsable by any library.
Example 2012-02-28T20:27:21+0000
In php use DateTimeZone and DateTime object combindly to get an ISO8601 date.
$dt = new DateTime("now", new DateTimeZone("UTC"));
echo $dt->format(DATE_ISO8601)`
See Date/Time in PHP manual to know more.
I think returning timestamp would be a better idea.
It allows your API users to manipulate it easily.
(My opinion)
Either do a integer unix timestamp or do full ISO8601.
RFC822 Format: 18 Feb 2012 14:27:18 -0000
DAY MONTH YEAR HOUR:MINUTES:SECONDS UTC-OFFSET
Using date():
date('d M y H:i:s O')
Twitter's API uses it, And some of its benefits are that it's readable by humans and easy to parse in PHP, JavaScript, And other languages. And you know which timezone the date is presented in.