Help with UNIX time to human time - php

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.

Related

How can I overwrite timestamp to save into the database base on specific timezone?

Right now my Laravel application save() any items into the database base on this timestamp. America/New_York because I configured it as 'timezone' => 'America/New_York', in config/app.php.
Goal
I wish to overwrite timestamp based on other tz instead, ex. America/Chicago
How do I do that?
You don't need too
MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.)
see https://dev.mysql.com/doc/refman/5.7/en/datetime.html
So when you change the server to another timezone all timestamps will get the new time zone
setting the time zone goe like
SET GLOBAL time_zone = 'America/Chicago';
You don't have to do crazy stuff... What you have to do is:
Store the time in a known timezone and never change that timezone again, it would be awesome if you use UTC as a default timezone.
When you want to "convert" a timezone, you just $model->created_at (or anything that is a Carbon object) and do $model->created_at->setTimezone('America/Chicago'); (for example).
The main idea is that when you already have a Carbon instance with a timestamp, you just change the timezone with setTimezone to the new one you want and it will return a new Carbon instance with that timezone...
Have a look at this SO topic.
Also, remember that timestamp is just an integer representing how many seconds have passed since 1970-01-01 00:00:01 (UTC), so if you say "give me a timestamp of a specific date and time on specific timezone" the timestamp will be always the same even if you change the timezone each time... that is the main idea of the timestamp...
If I say "What timestamp is for 1970-01-01 00:00:10?", if you are on UTC you would get 10, because 10 seconds passed since that specific datetime, if you are on UTC+1, it would still be 10 seconds, but you will display 1970-01-01 00:01:10, because you are 1 hour ahead of UTC, if you are on UTC-1 it will be 1969-12-31 23:00:10, because you are 1 hour behind UTC, but you know how to do the conversion, that is why the value will be always the same disregarding the timezone, and that is also why it is 1970-01-01 00:00:00 and not any other specific datetime, because if you do not know which is the specific datetime you would not know how to do the conversion.
It is very important that you understand what you are working with, so to help you understand better, have a look at this blog explaining the same thing but in more detail.
The timestamp generated in PHP is in UTC time regardless of your local timezone setting.
You can adjust the timezone of the timestamp before it is displayed in the UI using setTimezone.
Reference:
https://www.php.net/manual/en/function.time.php
https://www.php.net/manual/en/datetime.gettimestamp.php

What is the difference between these two date?

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.

PHP and timezone

I am using strtotime() to get a timestamp from a date and time string. I will be running strtotime() during the summer (daylight savings) to give me a timestamp of a winter date (non-daylight savings).
In the winter, I will need to convert my timestamp to a readable date using date() -- will it be the same date/time I put into strtotime() during the summer?
On each one of my pages, I am setting my timezone by date_default_timezone_set with my city.
So, running this during the summer (daylight savings):
date_default_timezone_set('America/Los_Angeles');
echo strtotime("Dec 1 2014 8:00 am");
Gives me a certain timestamp 1417449600.
Will running this during the winter (non-daylight savings) return 8:00am as I need it to do?
date_default_timezone_set('America/Los_Angeles');
echo date("g:ia",1417449600);
Yes. If the timezone you set is doesn't explicitly say whether it's standard or daylight-savings time, it automatically determines the state of DST from the time that you give it and the rules for when the timezone switches into and out of DST.
Yes. A UNIX timestamp such as 1417449600 represents a completely, globally, universally unique point in time, independent of fussy timezone notation. There's only one "December 1st 2014 8 am in Los Angeles", which is the same point in time as "December 1st 2014 17:00 CET" and a number of other local notations across the world. The UNIX timestamp 1417449600 expresses that point in time, regardless of whatever your wall clock says exactly.
When you format this unique point in time back to a more human readable format using date(), it figures out what exactly the time must be formatted at based on the set timezone. It won't change based on what the time or DST settings are now.

Why does strtotime give different result in different timezone?

I am not sure why strtotime() in PHP returns different result in different timezone even though same date is given as parameter, does anyone know the answer? I also want to know, can I do similar task (converting a datetime to an int to do calculations easily) with another function which gives same result across different timezone?
EDIT:
An example:
If I use strtotime('2011-09-19 00:00:00') shouldn't it just return the difference between 'January 1 1970 00:00:00' and '2011-09-19 00:00:00' in seconds ? Why timezone is an issue here? And can I get something which gives just difference without timezone issue?
In short: time zone is considered because the Unix Epoch value is considered in GMT.
In broader sense 2011-09-19 00:00:00 comes to Bangladesh almost after 6 hours it is 2011-09-19 00:00:00 in GMT zone. Because of this gap, another 21600 seconds have passed in the GMT zone when the same date appears in BD.
Since the calculation is done in respect to the GMT, you have to add these 21600 seconds to get the actual difference.
strtotime gives different results in different timezones because it takes timezones into account...
From strtotime's manual:
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)
This function will use the TZ environment variable (if available) to calculate the timestamp. Since PHP 5.1.0 there are easier ways to define the timezone that is used across all date/time functions. That process is explained in the date_default_timezone_get() function page.
Have a look at mktime().
Since PHP 5.1, you can use date_default_timezone_set before calling mktime or strtotime.
From the PHP manual:
This function will use the TZ environment variable (if available) to calculate the timestamp. Since PHP 5.1.0 there are easier ways to define the timezone that is used across all date/time functions. That process is explained in the date_default_timezone_get() function page.
http://php.net/manual/en/function.strtotime.php
Use date_default_timezone_set before calling date/time functions to choose which time zone you want to work in.
http://www.php.net/manual/en/function.date-default-timezone-set.php
From PHP docs on strtotime:
This function will use the TZ environment variable (if available) to
calculate the timestamp. Since PHP 5.1.0 there are easier ways to
define the timezone that is used across all date/time functions. That
process is explained in the date_default_timezone_get() function page.
Try setting your own time zone.
i think probably there will be one time of each php programmer that this function will make him wants to really understand how actually php works with date and time functions.
funny this function when you try something like...err...for example, assume that today at this very moment is July 11th, 2012 at 13:00:00 (2012-07-11 13:00:00) and then you try strtotime to find exactly the same moment of the day but for tomorrow:
$x = strtotime('2012-07-12 13:00:00');
$y = strtotime('+1 Day');
$z = $x-$y;
$x and $y of the above first 2 lines will not return the same thing even you ignore the minute and second counts but $z will be around 25200 or around 7 hours in the difference between this 2 lines if your sever is in somewhere of the USA that the GMT is -5 hours but you browser calls this function from berlin in summer where the GMT is +2 hours... LOL now you can get the idea how php work with this function ;)

Converting from GMT to UTC

In a table all the records are stored in GMT time. But through my application i want to display only those records which falls into timezone UTC. i.e., in a web page i want to display only records that comes under UTC time zone.
Converting from GMT to UTC. Or Query the database to get all the records of UTC timezone.
I really appreciate an early reply.
I am using oracle database and application in PHP.
From Greenwich Mean Time on Wikipedia:
It [GMT] is arguably the same as Coordinated Universal Time (UTC).
Regarding converting, you can add/remove intervals, but in so far as I'm aware, Oracle supports timestamps with/without time zones:
select now() at time zone 'UTC' as utc,
now() at time zone 'EST' as est,
now() at time zone 'Europe/London' as london;
The last example, if it works, would allow you to not worry about daylight savings and so forth.
I'll assume that your times are stored as DATE values, that all the values are stored as UTC times, and that the timezone you're interested in is constant. To convert from UTC to a given timezone you add the timezone's offset. In this case, since the timezone of interest has a negative offset you need to add in the same negative number. Thus, the following might be useful:
SELECT DATE_FIELD + INTERVAL '-5' HOUR
FROM SOME_TABLE
WHERE <whatever>
FWIW, there are some places where the conversion to local time uses a non-whole-hour offset - for example, Adelaide, Australia uses a +9.5 hour offset from GMT, and Kathmandu, Nepal uses +5.75 hours.
Share and enjoy.
EDIT: Given the data as you've described it, your best bet is probably to simply add in the session time zone, as follows:
SELECT your_gmt_timestamp_field AT TIME ZONE SESSIONTIMEZONE
FROM your_table
Give this a try and see if it helps.

Categories