I have unix timestamps created in a database table. I know user's timezone it is also saved in a table and int the format of "GMT+04:00" , "GMT+05:30"
What I'm trying to do is take the timestamp and show readable time to the users according to their timezone.
Ex.
$startTime = '1524391500';
echo date('h:ia', $startTime) . '<br>';
date_default_timezone_set('America/Fortaleza');
echo date('h:ia', $startTime) . '<br>';
this will give us the result
10:05am
07:05am
The problem is date_default_timezone_set doesn't accept the timezone in this
date_default_timezone_set('GMT+05:30');
So I need a way to convert "GMT+05:30" to something like "America/Fortaleza"
can some one help me with this?
What you ask for is not possible. A time zone and a time zone offset are two different things.
Consider a single time zone like America/Sao_Paulo. It uses an offset of -03:00 during Standard Time, and an offset of -02:00 during Daylight Saving Time.
Now consider that America/Fortaleza you mentioned uses -03:00 over the entire year.
As you can see, for a given time zone I may have more than one offset, and for a given offset I may have more than one time zone. You can review the lists of time zones and their offsets if you want to find more examples for yourself.
This is covered extensively in other answers, as well as in the "Time Zone != Offset" section of the timezone tag wiki.
Related
I used some api which gets the expiry date as
2021-07-09T14:09:47.529751-04:00
How do I process this and store it in the database.
Do I store this as datetime ?
Does it have any timezone associated with it ?
Is this correct but what do I do with the time zone. My server has a different time zone so if I store this value it would not be correct ?
echo date( "Y-m-d H:i:s", strtotime("2021-07-09T14:09:47.529751-04:00") );
The date format you're looking at is ISO 8601.
Strtotime() will convert it into an unix timestamp that is in UTC and you can save it to your database as a number. The number should be larger than 4 bytes so that you don't run in the Year 2038 problem. Everytime you read the value, you must convert it to the proper timezone of the user. This is the easy way. You'll never have to manually fix the dates in the database.
If you want to save it to database as a date, you probably want to still save the date as UTC and apply any transformations when you show the value. Convert it with gmdate() before saving:
echo gmdate( "Y-m-d H:i:s", strtotime("2021-07-09T14:09:47.529751-04:00") );
If you always show the value in one time zone, you can set the timezone in php.ini. This is not the best way though. It's best make it clear what timezone your program is using and explicitly set it in code.
When you want to show the value in other timezones, refer to this question or the manual of settimezone.
I know that questions about this topic have been asked over and over again, but all the reading just increased my confusion, so I decided to ask here.
I am working on a website where user can store Events, which are connected to a date. This date is stored in a mysql Database as type DATETIME.
So what I "just" would like to do is: Get the date from the Database and format it, but somehow, since the start of the Daylight Saving Time, ech date is shown minus one hour.
code:
$date = $item['date'] //<-- the result from the database (2015-11-27 08:15:00)
$dt = new DateTime($date, new DateTimeZone(date_default_timezone_get()));
echo $dt->format('G:i') // 8:15
The Value which was actually written in the "Date Field" of the administration form is 9:15 and that is what should be displayed.
Please correct me if I am wrong, but I think that "Summertime" seams to the common Basis. And the shift to "Wintertime" might be +1.
echo $dt->getOffset() // 3600s = 1 hour
If my assumtion is right, that offset should be zero in "Summertime", right? But that leads to the point I cannot sort out, since I am in the Timezone Europe/Berlin what itself is defined to be UTC +1
So which Offset does this getOffset() represent and how can I display the "right time"?
Thanks in Ahead!
In my "tool box" i'm using this function:
function dataAttuale() {
$now = new DateTime();
$dataAttuale = $now->format(DateTime::ISO8601);
$offset = $now->getOffset();
date_default_timezone_set('UTC');
$nowUTC = new DateTime();
$dataUTC = $nowUTC->format(DateTime::ISO8601);
$orario = array();
$orario['dataAttuale'] = $dataAttuale;
$orario['dataUTC'] = $dataUTC;
$orario['offset'] = $offset;
return $orario;
}
I get this array
Array
(
[dataAttuale] => 2013-10-18T11:03:52+0200
[dataUTC] => 2013-10-18T09:03:52+0000
[offset] => 7200
)
So i could save in a datetime MySql field a datetime referred to UTC.
Now, i've some trouble about this.
1) I would save also offset (in seconds). What's best Mysql field? I think max seconds can be +14hour * 60 * 60 = 50400 and -12hours*60*60 = -43200
2) Do you think is notable save also offset? I.e., for example, several API services return a date in UTC + offset...
Thank you very much!
UPDATE:
Thank you to both people. Now i'm saving in MySQL datetime in UTC format and varchar timezone. With a couple of code I'm getting what I want:
$orario = new DateTime($value['creazione'], new DateTimeZone($value['timezone']));
$orario = $orario->format(DateTime::ISO8601);
The output is (for Europe/Rome)
2013-10-19T09:27:54+0200
And for America/Montreal
2013-10-19T09:29:16-0400
And for Australia/Melbourne
2013-10-19T09:30:31+1100
(difference of minutes//seconds it the time to change in my PHP scripts the default Timezone).
Now I think that:
1) I can laugh about Y2038 bug, abandoning (sigh :( ) timestamp :(
2) I can safely travel around the world and use my own Calendar (naaaa... i'll use forever Google Calendar, of course)
It doesn't make a lot of sense to save the offset. There are two possible values you can be interested in with a timestamp:
the general global timestamp, e.g. "the point in time in this world at which it was 12:52am on Sept. 6 2013 UTC"
the specific local time of some point in time, e.g. "17:34 on Dec. 19th 2012 in Manila, Philippines"
Notice that both of these are actually the same thing, they express a point in time in the notation of wall clock time and date at a specific location or timezone. The only difference is that UTC is a specified standard "location" relative to which other timezone offsets are expressed; but there's no reason Manila in the Philippines couldn't be used for the same purpose.
So when you want to store an absolute timestamp, you either:
decide that all your times are stored in a specific timezone like UTC and simply store that timestamp
decide that you are interested in a specific local time and store the timestamp and its timezone
Either way you need the timestamp and you need to know which timezone it's in. In 1. you decide in advance that all timestamps are in the same defined timezone and don't need to store it, in 2. you explicitly save that timezone information.
An offset is not a good thing to store, because it varies throughout the year. The offset in summer may be +6 hours to UTC, but in winter may be +7. If you need to do date calculations on a localized time later on, an offset is misleading and doesn't help you much. If you know the timezone you're talking about, you can get the offset for any time of the year later on.
MySQL doesn't support a DATETIME + TIMEZONE field (Postgres for example does), so you need to store the timezone (e.g. "Europe/Berlin") in a separate text field. If you don't need to associate a timestamp with a specific location at all, then there's no need for a timezone and you just need to store the normalized timestamp, e.g. normalized to UTC.
MySQL is award of timezones (it does not store the timezone with the date, but it converts it to a normalized format), so most of the time you do not need to have an additional field with the offset.
You just need to make sure that you set the correct time_zone for your connection.
So if you have a date and you want to store it in your database you have different possibilities:
You can use SET time_zone = timezone; for your connection. Way you tell MySQL that the date you send or receive from MySQL should be in the give timezone. MySQL will internally convert it to a normalized format.
If you want to insert dates that have different timezones then set for the time_zone then you could use CONVERT_TZ(dt,from_tz,to_tz). from_tz is the timezone of your date, to_tz the one that is set for your connection.
There are for sure situations where the timezone could matter. If that is true for your case is not exactly clear out of your question.
I've looked through the other solutions on SO and none of them seem to address the timezone/dst issue in the following regard.
I am making calls to NOAA Tide Prediction API and NOAA National Weather Service API which require a time range to be passed for retrieving data. For each location in my database, I have the timezone as a UTC offset and whether daylight savings time is observed (either 1 or 0). I'm trying to format some dates (todays and tomorrow) to be what the LST (Local Standard Time) would be in it's own timezone so I can pass to these API's.
I'm having trouble figuring out how to know if a date, such as todays, is within the daylight savings time range or not.
Here is what I have so far:
// Get name of timezone for tide station
// NOTE: $locationdata->timezone is something like "-5"
$tz_name = timezone_name_from_abbr("", $locationdata->timezone * 3600, false);
$dtz = new DateTimeZone($tz_name);
// Create time range
$start_time = new DateTime('', $dtz);
$end_time = new DateTime('', $dtz);
$end_time = $end_time->modify('+1 day');
// Modify time to match local timezone
$start_time->setTimezone($dtz);
$end_time->setTimezone($dtz);
// Adjust for daylight savings time
if( $locationdata->dst == '1' )
{
// DST is observed in this area.
// ** HOW DO I KNOW IF TODAY IS CURRENTLY DST OR NOT? **
}
// Make call to API using modified time range
...
How can I go about doing this? Thanks.
You can use PHP's time and date functions:
$tzObj = timezone_open($tz_name);
$dateObj = date_create("07.03.2012 10:10:10", $tzObj);
$dst_active = date_format($dateObj, "I");
If DST is active on the given date, $dst_active is 1, else 0.
Instead of specifying a time in the call to date_create you can also pass "now" to receive the value for the current date and time.
However, like Jon mentioned, different countries within the same timezone offset may observe DST while others may not.
For each location in my database, I have the timezone as a UTC offset and whether daylight savings time is observed (either 1 or 0).
That's not enough information. There can be multiple time zones which all have the same standard offset, all observe DST, but perform DST transitions at different times. (Indeed, historically they may also start and stop observing daylight saving time for several years.)
Basically, your database should contain a time zone ID, not the offset/DST-true-or-false. (Assuming PHP uses the zoneinfo time zone database, a time zone ID is something like "Europe/London".)
EDIT: To find the offset of a given DateTime, you can call getOffset, which you can then compare with the standard time offset. But unless you have the definitive time zone ID, you will be risking getting the wrong zone.
Cillosis,
I hope you are not working with Java! I am and fought with time all the time. I also work with weather data. Most of the data I use is in local standard time (ignoring daylight saving time). I also need to use times from other time zones and found that Java kept reading my computer's time zone. I also kept running into deprecated classes. I came up with a solution that works. It is a bit of a kluge, so I have it heavily documented and it only exists in one function. My solution is relative time. I have set the local time to UTC. I am subtracting the GMT offset instead of adding it. I don’t really care about the actual times, all I care about is the difference between two times. It is working very well.
Good luck
For a while I had been using a raw MySQL NOW() function to record the time/date in my MySQL DB until I realized the host's timezone variable was three hours ahead of PST. I've fixed this using DATE_SUB(NOW(), INTERVAL 3 HOUR), but now I have a ton of timestamps that are three hours ahead, and all future timestamps that are the showing the correct time.
Is there a PHP function to evaluate timestamps recorded before I made the fix so I can offset them when they display in my admin utility?
For example:
if($timestamp < 2012-02-16 21:57:18) {
$timestamp - 3 hours;
}
New Timestamp (offset by 3 hours behind)
$timestamp = date('Y-m-d H:i:s',strtotime($row['timestamp_column_name'])-(3*60*60));
Create a second column in your table (perhaps?) and store the offset time - perhaps call it the admin time OR store the admin time offset from the system's time OR you can set the timezone PHP should use using something like the options mentioned here: PHP timezone not set .
the magical function strtotime does all the work for you. seriously check it out for adding, manipulating and even reading human readable forms of dates. Then the date function is good for formatting it back into any form.
For many input formats, strtotime is the way to go. However, its heuristical approach may lead to surprising results, so if you only want to parse a specific format, use strptime.