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?
Related
I am facing a problem with unix timestamps, php and mysql and would be great if somebody could explain to me where I am going wrong or if I am not then why I am getting the figures that I am getting.
When I use jquery datepicker to pass the date in year-month-date format to php the hour and minutes have been set by default of 23:00:00 in the timestamp even though I am not passing this infromation in the request. So my question is where is this phantom 23:00:00 appearing from?
Workflow:
Using datepicker: datepicker -> php -> mysql = TIMESTAMP which has time set at 23:00:00.
Without using datepicker: php->mysql = TIMESTAMP with the correct hour and minutes.
Thanks for reading.
EDIT: PHP code as requested:
PHP code:
$setdatealpha = $_POST['datepickeralpha'];
$setdatealpha = strtotime($setdatealpha);
// With this, I am inserting into MySQL like so:
$sql = "INSERT INTO TABLE (DATE_FIELD) VALUES (?)";
$stmt = $mysqli->prepare($sql);
$stmt->bind_param('s',$setdatealpha);
$stmt->execute();
Now when I read the entered information back and convert it to date time format via date('Y-m-d',timestamp), the date entry correct and the time entry has the 23:00:00 value.
This does not occur if I do a standard converstion via strtotime (date);
Based off of the information currently available, I would suggest that you make sure each timestamp is in UTC. I always run into timezone issues.
For PHP, like: $current_timestamp = strtotime($date." UTC");
For jQuery datepicker I found this stackoverflow thread: How to obtain utc time in jQuery datetimepicker
Most likely, time zone.
First of all, let's clarify the context. strtotime() produces a Unix timestamp, which you apparently feed DATE_FIELD with. If that works, it means that the column is an INTEGER. In the case, you're doing something afterwards to display the date and you haven't shared that part—also, MySQL is innocent here because it doesn't even know what DATE_FIELD is meant to be date.
While strtotime() can be fed with a raw date, it needs to generate time as well. It can't do it unless it knows the time zone. Additionally, when you have an integer variable with a Unix timestamp and you want to display it as proper date you also need to know the time zone.
In both cases, if you don't provide it PHP will use a default value:
var_dump(date_default_timezone_get());
So you'll possibly want to set a known one with e.g. date_default_timezone_set(). However, your users may have a different time zone than you so yours would be meaningless to them. Since you prompt the user for a raw date (without time) it's possible that time is actually not relevant to the question. In such case, you may want to:
Make DATE_FIELD of DATE type.
Avoid strtotime() and similar stuff. You may want to use checkdate() instead.
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've parsed openssl certificate by openssl_x509_parse() function and got an array as a result.
Now I need to get the expiration time of that certificate. In parsed array I have validTo_time_t element which contains a valid unix timestamp. But how to determine what timezone this timestamp belongs for?
So I can't get the real expiration time because that timestamp because it means deifferent dates on different timezones.
php formats this field using it's default timezone. you can get it using http://docs.php.net/date_default_timezone_get function
and once you know the timezone you can convert it to UTC or whatever you need
Unix TimeStamp have no timezone.
It's defined as number of seconds since January 1st, 1970 at UTC.
It's not a defined as a real date but just a bunch of seconds.
No timezone = no problems.
This is why it's a perfect measure of time across different server and different regions. You can just store unix timestamp, and when you convert it to a date it will use your local timezone to determinate the date, this is completly automatic and this means that when you convert givin a different timezone it will convert to the correct date. Always.
This is true for all timestamp not just for the SSL output.
Major info on Timestamp http://www.unixtimestamp.com/
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.
So I've got a text input that get's date & time in this format:
09/06/2010 21:08 (meaning September)
I'm using date_parse_from_format('m/d/Y H:i', $stringtoparse); (someone tell me if I'm incorrect here)
That function returns an associative array with indexes like "year" or "day" or "hour".
The original text that was sent in needs to be treated as though it were in a certain timezone. It'll always be EST, but I'm just having troubles figuring out how to adjust for the timezone anyway.
Basically, in the end, there will be two datetimes in the database (a start time and an end time). I need to know if the current time is in between those two times. I know once I have a final timestamp I can just use:
$startdate < now() < $enddate or something like such (of course now needs to be in the format of "EST", but I need to be sure timezones are correct first. How do I do this?
You should store all dates in single timezone, we have chosen UTC for DB storage and are converting it to user's timezone on render.
You are not incorrect, however I recommend using DateTime::createFromFormat instead.