I'm totally confused with PHP UTC/Local time conversions. Some functions convert time implicitly, some don't. Argh!!!
Say, I have this PHP code:
$timestamp = strtotime("2016-05-13 09:26:30"); //From MySQL date format
//$timestamp returned is 1463153190
Then if I convert 1463153190 to UTC time, it becomes 05/13/2016 # 3:26pm (UTC). Why???
How do I get a function to convert time from string to a timestamp one-to-one, without any time-zone shenanigans?
2016-05-13 09:26:30 is an incomplete timestamp, since it's missing the timezone. It could refer to over 24 different "absolute points in time", depending on which timezone it's being interpreted in. 1463153190 is an absolute UNIX timestamp for an absolute point in time. To convert your former timestamp to an absolute point in time, it needs to be interpreted as some timezone. The conversion the other way around also needs some timezone to format the point in time in.
In PHP the default timezone is considered when converting to or from UNIX timestamps. You can set that using date_default_timezone_set.
You see what you're seeing because date_default_timezone is set to some timezone (~+6) when converting from the human readable format to the UNIX timestamp, but then you're converting it back explicitly using UTC. Your initial timezone was simply not UTC/the timestamp was not initially interpreted as being in UTC. There's a timezone mismatch between the initial value and the final value, hence an offset of 6 hours.
Related
I am just beginner in Laravel and as I watching certain tutorials on YouTube and author to change
format of created_at and updated_at in the view changed from string to unix timestamp and would like to ask
why we need to convert date from string to unix timestamp with the use
of strtotime function. Can't we still use string rather than
converting it to unix timestamp.
Secondly, why exactly unix timestamp over date time. Are there any
advantages of unix timestamp over date time
You do not need to use it unless you are required. You will know the reason if you ever required it.
The purpose of the function as per the PHP manual is,
The function expects to be given a string containing an English date format and will try to parse that format into a Unix timestamp (the number of seconds since January 1 1970 00:00:00 UTC), relative to the timestamp given in now, or the current time if now is not supplied.
In summary, it converts the date given in English to the number of seconds in Numeric.
I'm working on something where the user can select their own timezone and the software will be able to be used by others on their sites as well but I want to make sure that the timezone within the database is always set to UTC.
Now I know how you set the default timezone for PHP, such as:
date_default_timezone_set('Australia/Sydney');
...but I'm not sure how to make sure MySQL is using UTC? ...and even once you have made sure it is using UTC I guess you would have to convert your PHP dates/times into UTC before passing it to the database?
I guess I am wondering about many different date formats such as TIMESTAMP, DATETIME & even UNIX EPOCH integer timestamps which would simply be stored as a int datatype for example.
Then there is the whole retrieving dates/times from the DB and converting it to the respective timezone and lastly how does DST come into all of this?
I know there is a lot of similar questions out there, but I guess none really answered all my questions.
MySQL's data type timestamp stores the dates in UTC. For this to work properly, MySQL uses server's time zone and does the date conversion. It converts the date from servers's current time zone to UTC for storage. This implies that the database server should never change its time zone for this feature to work properly.
When you send the data to such a database, you send the UTC time as well. The easiest way to do this is to format a result of time() according to what MySQL wants (m-d-Y H:i:s).
In PHP, when you format the date for insertion to MySQL, it's the best to use DateTime class. It lets you offset the date with the time zone information, meaning that you don't have to use date_default_timezone_set function - that can lead to mistakes.
An example of DateTime in action:
$date = '1.12.2015 13:37:37'; // Format is day.month.year hour:minute:second
// We create DateTime from custom date format, for the person who resides in Australia/Sydney time zone
$dt = DateTime::createFromFormat('d.m.Y H:i:s', $date, new DateTimeZone('Australia/Sydney');
// Now we change the date's time zone into UTC, and we can insert it into MySQL
$dt->setTimeZone(new DateTimeZone('UTC'));
// This is the formatted date-string that can be safely inserted into MySQL
$date_string_for_mysql = $dt->format('m-d-Y H:i:s');
Alternatively, you can use int type in MySQL for timestamp storage and insert result of time() but this has a huge disadvantage of not being able to use date-related functions.
for current session of mysql you can try something like
SET time_zone = timezonename;
for more details you can also look into this answer https://dba.stackexchange.com/questions/20217/mysql-set-utc-time-as-default-timestamp
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/
I need to format a UNIX timestamp in GMT format to a local date/time. I'm using gmstrftime to do this and I can get the correct result if I use an offset. I just so happen to know what my offset is for the pacific timezone but I don't want to have to get the correct time like this. I've used date_default_timezone_set so gmstrftime is reporting the correct timezone but the time is off by like a day.
I don't get it. If gmstrftime knows what timezone I'm in, why is the time off?
If you have the correct timezone set (such as with date_default_timezone_set) then you only need to use date() for the formatting, no extra coding. UNIX timestamps are in GMT by definition of a UNIX timestamp -- number of seconds since January 1, 1970 00:00:00 GMT.
gmstrftime will always return the time as UTC, seems like you want strftime.