I have some localisation functions within my webapp (exposed via Ajax) which enable users to display some datetime information in their own timezone as well as the timezone relating to the location of the entity the data primarily relates to.
As a result of some testing, I've discovered that whilst my code is capable of converting DB sourced date/time values accurately (i.e. including DST adjustments), the code would not calculate the correct offsets when I was using dates provided within a form. The best I've been able to achieve is converting the form date/time value to UTC but the incorrect offset is applied. This means that I need to check whether the date falls within the daylight savings range and if so, pull the datetime value back by an hour. This seems like an ugly fix and I'd appreciate it if anyone knows where I've gone wrong:
Example:
Input value of 25/11/2018 16:00 NZDT (Pacific/Auckland) = UTC+13
Output value should be 25/11/2018 14:00 ADT (Australia/Sydney) = UTC+11
If I extract the source value from the Database and then convert then the calculations work fine, no issues
If I use a form provided value (which I need to check for in case the user has updated the value without saving it), then the following occurs:
FROM DB1 = 2018-11-25 03:00:00 (value in the DB, in UTC)
FROM FORM1 = 25/11/2018 16:00 (raw value from the form)
FROM FORM2 = 2018-11-25 04:00:00 (changes to UTC-12, i.e. NZST) which is wrong, should be the same value as DB1, i.e. UTC-13 which is the offset from NZDT back to UTC)
FROM FORM3 = 2018-11-25 03:00:00 (corrected, once I check whether date/time value falls within a daylight savings range)
Code follows:
echo "FROM DB1: ".$getListing['lo_deadline']."<BR />";
echo "FROM FORM1:".$in_lo_deadline."<BR />";
$frmDateTime = DateTime::createFromFormat($this->view->user->user_datetimeformat, $in_lo_deadline,new DateTimeZone($list_tmzn));
echo "FROM FORM2:".$frmDateTime->format('Y-m-d h:i:s')."<BR />";
//If $frmDateTime is in daylight savings then subtract an hour to arrive at the correct UTC value
if ($frmDateTime->format('I'))
{
date_sub($frmDateTime, date_interval_create_from_date_string('1 hours'));
}
echo "FROM FORM3:".$frmDateTime->format('Y-m-d h:i:s')."<BR />";
$dates['set_dead'] = convertUserDate($frmDateTime->format('Y-m-d h:i:s'), $this->view->user->user_datetimeformat, $user_tmzn,'UTC');
What I understand from your code, the reason why it's showing 2018-11-25 04:00:00 is because of AM/PM format. You should be using capital H instead of h in your code.
You need to understand the difference between 24 hour and 12 hour formats. 2018-11-25 04:00:00 according to your format is in AM/PM or 12 hour format, but in 24 hour format it should be 2018-11-25 16:00:00. Database time is always in 24 hour format.
Change
$frmDateTime->format('Y-m-d h:i:s')
to
$frmDateTime->format('Y-m-d H:i:s')
Note: You don't need to manually subtract an hour to calculate daylight saving time as php does it automatically.
Related
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!
I'm using Laravel/PHP/MySQL and storing all dates and times in UTC.
The user can select a timezone (for example Eastern), enter a date and time, and the date and time will be converted to UTC before storing. On retrieval it will be converted to user's selected timezone.
My question is how can you get the average time of day from a series of records taking into account the timezone (preferably in the database query)? The following question addresses average time of day in PHP, but not the timezone issue.
How to calculate average time
Here is what I'm doing:
SEC_TO_TIME( AVG( TIME_TO_SEC( TIME(flights.departed_at) ) ) ) ) AS average_time
This works except for records that span daylight saving/standard time in a region that observes it.
FOR EXAMPLE: You may have a record with the UTC datetime of 2015-08-18 11:00:00 that was entered by a user in EDT at 2015-08-18 07:00:00. Then you have a second record entered with the UTC datetime of 2015-11-10 12:00:00 by a user in EST at 2015-11-10 07:00:00. If you try to calculate the average time of day it should equate to 07:00:00 but instead the result is 07:30:00.
Any ideas how to overcome this? Am I approaching this all wrong?
Thanks in advance.
In short, your code is working correctly. Once the date is in UTC, you'd have to re-calculate whether or not it was entered (1) during daylight savings time, (2) by someone actually observing daylight savings time, and (3) in a place that recognizes daylight savings time.
I can really only think of one way to approach this.
Add some kind of flag when the data is saved to mark the timestamp as DST. You can use this flag to adjust for the hour difference. How you generate this flag is up to you.
If you have all your times stored in Z, and if your MySQL database has the timezones loaded correctly, you can use the zoneinfo timezone name to retrieve your local times. For example,
SELECT CONVERT_TZ('2015-08-01 11:00', 'UTC', 'America/New_York'),
CONVERT_TZ('2015-12-01 12:00', 'UTC', 'America/New_York')
yields
2015-08-01 07:00 2015-12-01 07:00
The point is, the zoneinfo database knows to use daylight saving time or standard time for each datetime value. It doesn't use the current offset, it uses the offset in effect on the date in question.
So, you can retrieve the time of day, in local time, with an expression like this:
TIME(CONVERT_TZ(utc_time_column, 'UTC', 'America/New_York'))
Then, you average those times-of-day in the usual way.
I have a table with a field of type date within a MySQL database. My user places a date into a field (format dd-mm-yyyy) which I convert into yyyy-mm-dd for insertion into the database. This works fine. I can see the date in there as (for example) 2012-04-04.
My issue is that I then select this record, convert the date to the format I wish to display (dd-mm-yyyy) and get 03-04-2012. I understand why, in that my database is set to UTC, however the user is on Berlin time, therefore 04-04-2012 00:00 in Berlin is 03-04-2012 23:00 UTC.
The issue means that if I then save the displayed date (03-04-2012), the next time I see it, it displays as 02-04-2012 because I saved only the date and therefore the system is assuming a 00:00 time again.
I cannot see a way around this other than setting this as a datetime type rather than a date type, however I would rather not do that as time (for various reasons) is stored in a separate field. Any suggestions?
When you inserting a record you add as datetime current UTC time, after that every user in their profile may want to/or set his timezone.
If you know the timezone of the user u can easy convert the datetime to user locale time. Because you know the differences in hours/minutes between the time.
P.S. You can store the datetime as varchar and save the unix timestamp in this field. Unix timestamp is based on current timezone I think.
UPDATE:
I think that might help
$date = time();
dump(date('d-m-Y H:i:s', $date)); // 03-04-2012 08:43:38
date_default_timezone_set('Europe/London');
dump('London: '. date('d-m-Y H:i:s', $date)); // London: 03-04-2012 11:43:38
date_default_timezone_set('Europe/Berlin');
dump('Berlin: '. date('d-m-Y H:i:s', $date)); // Berlin: 03-04-2012 12:43:38
date_default_timezone_set('Europe/Sofia');
dump('Sofia: '. date('d-m-Y H:i:s', $date)); // Sofia: 03-04-2012 13:43:38
dump function returns '<pre>'. $something .'</pre>';
UTC is the international time standard. It is similar to Greenwich Mean Time (GMT), except that UTC observes no daylight saving time (DST) and is based on a 24-hour clock. Zero (0) hours UTC is midnight GMT. The local 24-hour time convention is converted to UTC by adding or subtracting hours based on location in relation to the prime meridian, as well as local daylight saving time considerations.
First, make sure both time zones are same. Then, don't store in datatime format, use integer. Convert the date to timestamps and then store. Like
$time = time(); //get the current time stamp
//Now insert $time
Now, both places are in common ground, You may do as you like. Changing date among different timezone is rather easy.
echo gmdate("M d Y H:i:s", $time);
I wanted to ask if this was going to work, before I went on a full fledged refactor of how i handle dates and times.
To frame my question, here's my problem...
I store "actions" taken by the user in a history table. These actions have a timestamp on them. Users can be from all over the world, and hence have different timezones. I want to display the items in the history and show the timestamps in one's local timezone.
Also, I know I can use datetime fields and simply store UTC time formats, but I'm opting to use timestamp so i can set a default to current time.
Will this work for my problem?
My server time zone will be Los Angeles
Store timestamps as a timestamp in MySQL. My understanding is that timestamp is always stored as UTC. Records will be stored by default as creation_date OR i will explicitly set UTC_TIMESTAMP(). Effictively, all records in the db will be UTC.
When a user logs in I will grab their timezone (I store this in the db as a user setting).
For this example, lets say this person is in New York.
Here's where my question is. Will either of these work?
a) Grab the history data. All timestamps will automatically be converted from UTC to Los Angeles time. Foreach history item, convert the Los Angeles timestamp to New York timestamp and echo.
OR
b) Set the php timezone "date_default_timezone_set" to New York. Grab the history data. All timestamps are STILL in Los Angeles time by server is still Los Angeles time. Foreach history item, just echo the timestamp because the "date_default_timezone_set" will automatically convert the Los Angeles timestamp to New York.
Will option 4b work? Is there a better way to convert from the Los Angeles time to the New York time?
Is there a better way to do this in general?
You are correct, Unix timestamps are always in UTC. If you store the timestamps in your database in UTC, all you need to do to output it in local time is change the timezone in PHP to the timezone local to the user. You don't need to do any conversion on the timestamps.
<?php
$timeStampFromDatabase = 1325448000; // 01 Jan 2012 20:00:00 GMT
date_default_timezone_set('America/Los_Angeles');
echo date('r', $timeStampFromDatabase); // Sun, 01 Jan 2012 12:00:00 -0800
date_default_timezone_set('Asia/Hong_Kong');
echo date('r', $timeStampFromDatabase); // Mon, 02 Jan 2012 04:00:00 +0800
You can change your timezone on the fly and continue to output timestamps in a date format and they will be "converted" based on the set timezone in PHP. It is very easy, you don't need to do any special handling, and it doesn't matter where you set the timezone, as long as you do it before you output dates, but you can read them prior to setting the timezone.
Unfortunately, "date_default_timezone_set" was not working the way I thought it would. As per the previous example, it would work if the dates I was working with were already in unix timestamp format. However, they were formatted in "Y-m-d H:i:s" and the only thing that would change was the GMT offset, which obviously doesnt work.
After a few hours of fidgeting, here's how I was able to handle time conversions.
$datetime = new DateTime($date_to_convert);
$usertimezone = new DateTimeZone($_SESSION['timezone']); //each user has their own timezone i store in a session (i.e. - "Americas/Los_Angeles")
$datetime->setTimezone($usertimezone);
echo $datetime->format("Y-m-d H:i:s");
I suppose that I could have done the following as well:
Pseudo code
strtotime($datetime)
date_default_timezone_set($user_timezone)
echo date(format, $datetime)
the above, i think, would force the date function to handle it's logic in the given $user_timezone. in hindsight, i would have to translate every $datetime -> unix_timestamp -> $datetime_converted, which doesnt sound to be much better than what i chose to do.
Always store your timestamps in the database as UTC. This is a timezone and daylight savings independent point in time time. To display this back to the user in their timezone, simply do:
$users_timezone = 'Europe/London'; // See PHP documentation for names that can be used.
$date = new DateTime();
$date->setTimestamp($timestamp_from_database);
$date->setTimezone(new DateTimeZone($users_timezone));
echo $date->format("H:ia jS F Y");
By default, Unix timestamps are always in UTC. If we store the timestamps in our database in UTC, we just need to use the following PHP script:
<?php
$TZ_UTC = new DateTimeZone('UTC'); //-->Database Timezone;
$TZ_LOCAL = new DateTimeZone('America/New_York'); //-->Expected Local Timezone from user settings;
//--Example Database Query--
while($row = mysqli_fetch_array($result, MYSQLI_ASSOC)) {
//---If we want to show UTC timezone directy----
echo $row['action_timestamp'];
//---If we want to show LOCAL timezone from user settings----
$dateObj = new DateTime($row['action_timestamp'], $TZ_UTC);
$dateObj->setTimezone($TZ_LOCAL); //--> Here is the conversion!
echo $dateObj->format("Y-m-d H:i:s T");
}
?>
I'm using the America/New York timezone. In the Fall we "fall back" an hour -- effectively "gaining" one hour at 2am. At the transition point the following happens:
it's 01:59:00 -04:00
then 1 minute later it becomes:
01:00:00 -05:00
So if you simply say "1:30am" it's ambiguous as to whether or not you're referring to the first time 1:30 rolls around or the second. I'm trying to save scheduling data to a MySQL database and can't determine how to save the times properly.
Here's the problem:
"2009-11-01 00:30:00" is stored internally as 2009-11-01 00:30:00 -04:00
"2009-11-01 01:30:00" is stored internally as 2009-11-01 01:30:00 -05:00
This is fine and fairly expected. But how do I save anything to 01:30:00 -04:00? The documentation does not show any support for specifying the offset and, accordingly, when I've tried specifying the offset it's been duly ignored.
The only solutions I've thought of involve setting the server to a timezone that doesn't use daylight savings time and doing the necessary transformations in my scripts (I'm using PHP for this). But that doesn't seem like it should be necessary.
Many thanks for any suggestions.
I've got it figured out for my purposes. I'll summarize what I learned (sorry, these notes are verbose; they're as much for my future referral as anything else).
Contrary to what I said in one of my previous comments, DATETIME and TIMESTAMP fields do behave differently. TIMESTAMP fields (as the docs indicate) take whatever you send them in "YYYY-MM-DD hh:mm:ss" format and convert it from your current timezone to UTC time. The reverse happens transparently whenever you retrieve the data. DATETIME fields do not make this conversion. They take whatever you send them and just store it directly.
Neither the DATETIME nor the TIMESTAMP field types can accurately store data in a timezone that observes DST. If you store "2009-11-01 01:30:00" the fields have no way to distinguish which version of 1:30am you wanted -- the -04:00 or -05:00 version.
Ok, so we must store our data in a non DST timezone (such as UTC). TIMESTAMP fields are unable to handle this data accurately for reasons I'll explain: if your system is set to a DST timezone then what you put into TIMESTAMP may not be what you get back out. Even if you send it data that you've already converted to UTC, it will still assume the data's in your local timezone and do yet another conversion to UTC. This TIMESTAMP-enforced local-to-UTC-back-to-local roundtrip is lossy when your local timezone observes DST (since "2009-11-01 01:30:00" maps to 2 different possible times).
With DATETIME you can store your data in any timezone you want and be confident that you'll get back whatever you send it (you don't get forced into the lossy roundtrip conversions that TIMESTAMP fields foist on you). So the solution is to use a DATETIME field and before saving to the field convert from your system time zone into whatever non-DST zone you want to save it in (I think UTC is probably the best option). This allows you to build the conversion logic into your scripting language so that you can explicitly save the UTC equivalent of "2009-11-01 01:30:00 -04:00" or ""2009-11-01 01:30:00 -05:00".
Another important thing to note is that MySQL's date/time math functions don't work properly around DST boundaries if you store your dates in a DST TZ. So all the more reason to save in UTC.
In a nutshell I now do this:
When retrieving the data from the database:
Explicitly interpret the data from the database as UTC outside of MySQL in order to get an accurate Unix timestamp. I use PHP's strtotime() function or its DateTime class for this. It can not be reliably done inside of MySQL using MySQL's CONVERT_TZ() or UNIX_TIMESTAMP() functions because CONVERT_TZ will only output a 'YYYY-MM-DD hh:mm:ss' value which suffers from ambiguity problems, and UNIX_TIMESTAMP() assumes its input is in the system timezone, not the timezone the data was ACTUALLY stored in (UTC).
When storing the data to the database:
Convert your date to the precise UTC time that you desire outside of MySQL. For example: with PHP's DateTime class you can specify "2009-11-01 1:30:00 EST" distinctly from "2009-11-01 1:30:00 EDT", then convert it to UTC and save the correct UTC time to your DATETIME field.
Phew. Thanks so much for everyone's input and help. Hopefully this saves someone else some headaches down the road.
BTW, I am seeing this on MySQL 5.0.22 and 5.0.27
MySQL's date types are, frankly, broken and cannot store all times correctly unless your system is set to a constant offset timezone, like UTC or GMT-5. (I'm using MySQL 5.0.45)
This is because you can't store any time during the hour before Daylight Saving Time ends. No matter how you input dates, every date function will treat these times as if they are during the hour after the switch.
My system's timezone is America/New_York. Let's try storing 1257051600 (Sun, 01 Nov 2009 06:00:00 +0100).
Here's using the proprietary INTERVAL syntax:
SELECT UNIX_TIMESTAMP('2009-11-01 00:00:00' + INTERVAL 3599 SECOND); # 1257051599
SELECT UNIX_TIMESTAMP('2009-11-01 00:00:00' + INTERVAL 3600 SECOND); # 1257055200
SELECT UNIX_TIMESTAMP('2009-11-01 01:00:00' - INTERVAL 1 SECOND); # 1257051599
SELECT UNIX_TIMESTAMP('2009-11-01 01:00:00' - INTERVAL 0 SECOND); # 1257055200
Even FROM_UNIXTIME() won't return the accurate time.
SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(1257051599)); # 1257051599
SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(1257051600)); # 1257055200
Oddly enough, DATETIME will still store and return (in string form only!) times within the "lost" hour when DST starts (e.g. 2009-03-08 02:59:59). But using these dates in any MySQL function is risky:
SELECT UNIX_TIMESTAMP('2009-03-08 01:59:59'); # 1236495599
SELECT UNIX_TIMESTAMP('2009-03-08 02:00:00'); # 1236495600
# ...
SELECT UNIX_TIMESTAMP('2009-03-08 02:59:59'); # 1236495600
SELECT UNIX_TIMESTAMP('2009-03-08 03:00:00'); # 1236495600
The takeaway: If you need to store and retrieve every time in the year, you have a few undesirable options:
Set system timezone to GMT + some constant offset. E.g. UTC
Store dates as INTs (as Aaron discovered, TIMESTAMP isn't even reliable)
Pretend the DATETIME type has some constant offset timezone. E.g. If you're in America/New_York, convert your date to GMT-5 outside of MySQL, then store as a DATETIME (this turns out to be essential: see Aaron's answer). Then you must take great care using MySQL's date/time functions, because some assume your values are of the system timezone, others (esp. time arithmetic functions) are "timezone agnostic" (they may behave as if the times are UTC).
Aaron and I suspect that auto-generating TIMESTAMP columns are also broken. Both 2009-11-01 01:30 -0400 and 2009-11-01 01:30 -0500 will be stored as the ambiguous 2009-11-01 01:30.
I think micahwittman's link has the best practical solution to these MySQL limitations: Set the session timezone to UTC when you connect:
SET SESSION time_zone = '+0:00'
Then you just send it Unix timestamps and everything should be fine.
But how do I save anything to 01:30:00
-04:00?
You can convert to UTC like:
SELECT CONVERT_TZ('2009-11-29 01:30:00','-04:00','+00:00');
Even better, save the dates as a TIMESTAMP field. That's always stored in UTC, and UTC doesn't know about summer/winter time.
You can convert from UTC to localtime using CONVERT_TZ:
SELECT CONVERT_TZ(UTC_TIMESTAMP(),'+00:00','SYSTEM');
Where '+00:00' is UTC, the from timezone , and 'SYSTEM' is the local timezone of the OS where MySQL runs.
Mysql inherently solves this problem using time_zone_name table from mysql db.
Use CONVERT_TZ while CRUD to update the datetime without worrying about daylight savings time.
SELECT
CONVERT_TZ('2019-04-01 00:00:00','Europe/London','UTC') AS time1,
CONVERT_TZ('2019-03-01 00:00:00','Europe/London','UTC') AS time2;
This thread made me freak since we use TIMESTAMP columns with On UPDATE CURRENT_TIMESTAMP (ie: recordTimestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) to track changed records and ETL to a datawarehouse.
In case someone wonder, in this case, TIMESTAMP behave correctly and you can differentiate between the two similar dates by converting the TIMESTAMP to unix timestamp:
select TestFact.*, UNIX_TIMESTAMP(recordTimestamp) from TestFact;
id recordTimestamp UNIX_TIMESTAMP(recordTimestamp)
1 2012-11-04 01:00:10.0 1352005210
2 2012-11-04 01:00:10.0 1352008810
I was working on logging counts of visits of pages and displaying the counts in graph (using Flot jQuery plugin). I filled the table with test data and everything looked fine, but I noticed that at the end of the graph the points were one day off according to labels on x-axis. After examination I noticed that the view count for day 2015-10-25 was retrieved twice from the database and passed to Flot, so every day after this date was moved by one day to right.
After looking for a bug in my code for a while I realized that this date is when the DST takes place. Then I came to this SO page...
...but the suggested solutions was an overkill for what I needed or they had other disadvantages. I am not very worried about not being able to distinguish between ambiguous timestamps. I just need to count and display records per days.
First, I retrieve the date range:
SELECT
DATE(MIN(created_timestamp)) AS min_date,
DATE(MAX(created_timestamp)) AS max_date
FROM page_display_log
WHERE item_id = :item_id
Then, in a for loop, starting with min_date, ending with max_date, by step of one day (60*60*24), I'm retrieving the counts:
for( $day = $min_date_timestamp; $day <= $max_date_timestamp; $day += 60 * 60 * 24 ) {
$query = "
SELECT COUNT(*) AS count_per_day
FROM page_display_log
WHERE
item_id = :item_id AND
(
created_timestamp BETWEEN
'" . date( "Y-m-d 00:00:00", $day ) . "' AND
'" . date( "Y-m-d 23:59:59", $day ) . "'
)
";
//execute query and do stuff with the result
}
My final and quick solution to my problem was this:
$min_date_timestamp += 60 * 60 * 2; // To avoid DST problems
for( $day = $min_date_timestamp; $day <= $max_da.....
So I am not staring the loop in the beginning of the day, but two hours later. The day is still the same, and I am still retrieving correct counts, since I explicitly ask the database for records between 00:00:00 and 23:59:59 of the day, regardless of the actual time of the timestamp. And when the time jumps by one hour, I am still in the correct day.
Note: I know this is 5 year old thread, and I know this is not an answer to OPs question, but it might help people like me who encountered this page looking for solution to the problem I described.