PHP date issues with daylight saving - php

I've got a very strange bug cropping up in some PHP code I've got. The page is managing student enrolments in courses. On the page is a table of the student's courses, and each row has a number of dates: when they enrolled, when they completed, when they passed the assessment and when they picked up their certificate.
The table data is generated by PHP (drawing the data from the DB), and Javascript actually renders the table. The output from PHP is JS code which looks something like this:
var e = new Enrolment();
e.contactId = 5801;
e.enrolId = 14834;
e.courseId = 3;
e.dateEnrolled = new Date(1219672800000);
e.dateCompleted = new Date(-1000); // magic value meaning they haven't completed.
e.resultDate = new Date(1223647200000);
e.certDate = new Date(1223560800000);
e.result = 95;
e.passed = true;
enrolments[14834] = e;
In the database, all the date fields are stored as DATE (not DATETIME) fields.
The bug is that the dates are being displayed as one day off. I would suspect that this has a lot to do with the server being in an area which has daylight saving, whereas here there isn't any (meaning the server time is one hour off). This explains a lot, especially how the data preparation and rendering is being done in two different timezones. That is: the server is saying to the client that the person completed at midnight on the 15th August, and the client is interpreting that as 11pm on the 14th and therefore displaying 14th August.
But here's the confusing part: it's only doing that for the resultDate and certDate fields! I've copied the data to my local server and have found that the production server is actually sending a different timestamp (one which is off by 1 hour) just for those two fields, whereas the dateEnrolled field is the same.
Here's the output using the exact same code and data from the database:
// local server (timezone GMT+1000)
e.dateEnrolled = new Date(1219672800000); // 26 Aug 2008 00:00 +10:00
e.dateCompleted = new Date(-1000);
e.resultDate = new Date(1223647200000); // 11 Oct 2008 00:00 +10:00
e.certDate = new Date(1223560800000); // 10 Oct 2008 00:00 +10:00
// production server (timezone GMT+1100)
e.dateEnrolled = new Date(1219672800000); // 26 Aug 2008 00:00 +10:00
e.dateCompleted = new Date(-1000);
e.resultDate = new Date(1223643600000); // 10 Oct 2008 23:00 +10:00 **
e.certDate = new Date(1223557200000); // 09 Oct 2008 23:00 +10:00 **
I can understand if this was a problem with Daylight Saving not being accounted for, but notice how the dateEnrolled is the same?
The PHP code which converts the MySQL date to a unix timestamp is this:
list ($year, $month, $day) = explode ('-', $mysqlDT);
$timestamp = mktime (0,0,0, $month, $day, $year);
Any ideas about how to fix this?

Thats because you use mktime which is locale specific. That is it will convert it to the number of seconds from 00:00:00 1970-1-1 GMT, and that is offset by 1 hour with one timezone.
You should also remember that the javascript does use the same timezone as the browser, not the web page.
e.resultDate = new Date(year, month - 1, day);
This will make sure the date is the same for every viewer from every timezone.
Or you can use gmmktime and use the UTC methods in Date.

Ok, I just figured out why it's mucking up one date but not the other. Daylight savings wasn't in effect in August. facepalm

always store dates/datetimes in GMT/UTC
take a good look at the query that retrieves these values, anything different about the ones being adjusted?
if not, are they all timestamp or date or datetime?

It is mosly likely to be day light saving issue.
The reason why it doing it only for resultDate and certDate is that dateEnrolled is in August, daylight saving normally begins/ends in late September or early October.

Set the date.timezone ini setting to your app's timezone, using apache.conf, .htaccess or ini_set().

Related

PHP DateTime::createFromFormat behavoiur

Today I've encountered something confusing for me with the behaviour of the \DateTime::createFromFormat function.
In my case I have a string, representing the date in the following format m/Y (05/2017). When I want to convert the string to DateTime object I've encountered the following issue:
$date = \DateTime::createFromFormat('m/Y', '02/2017');
When I dump the $date variable, the date property inside is '2017-03-03 11:06:36.000000'
But if I add the date before the month $date = \DateTime::createFromFormat('d/m/Y', '01/02/2017'); I get back an object with correct date property. (unfortunately I cant change the format of the date and add the day. It must be m/Y).
The fix I've come up with is to concatenate the first day of the month to the date string I have $date = '01/'.$dateString; but I rather not to do that because it's hardcoded.
What is wrong here? Does the createFromFormat function lack information of how to create the object? I'm quite confused with this. Thanks for everyone's help in advance!
By default, PHP will populate missing date values with those of the current date/time; so
$date = \DateTime::createFromFormat('m/Y', '02/2017');
will populate the missing day value with the current date; and as 31st February is an invalid date, it will roll forward into March. Likewise, hours/minutes/seconds will be populated with the missing time values based on the current time.
If you want to force the behaviour of forcing to the beginning of the month/time, then modify your mask with a leading !
$date = \DateTime::createFromFormat('!m/Y', '02/2017');
This will populate the missing day with the 1st of the month, and the time with 00:00:00
Alternatively, a trailing | will have the same effect
$date = \DateTime::createFromFormat('m/Y|', '02/2017');
You cannot store incomplete dates, not at least in a dedicated date format that can be used for complex date calculations (nothing prevents you from creating your own MonthYear class). So when you create a DateTime() object with incomplete information something needs to happen:
Crash
Use some default values
PHP opts for the second option and makes a decision inherited from the C language date library:
Assume that missing data means "now"
Try to fix automatically the invalid dates that this algorithm can create
In this case, Feb 2017 becomes 31 Feb 2017 (because "now" is 31 May 2017) and PHP follows this reasoning: February only had 28 days in year 2017 but I have three more; the user probably wants to move these three extra days into March. Thus 3 Mar 2017.
I see no reason to avoid hard-coding 01 because, after all, it is a hard-coded value (why the first day of the month and not the last one or any other day?).
$input = '05/2017';
$date = \DateTime::createFromFormat('d/m/Y', "01/$input");

PHP & MySQL are returning different dates for same timestamp

I am encountering a slightly frustrating problem and I have a feeling there is a simple solution to it. When I pass the same UNIX timestamp to the PHP date and MySQL FROM_UNIXTIME methods they are returning two very different dates. I would like to return a value from MySQL that matches the one returned by PHP.
Here is the code I am currently using along with it's output. The timestamp provided represents the date Tue, 01 Jan 2013 (01/01/2013). Also for reference, here are the format values.
MySQL Format
%j = Day of year (001..366).
%m = Month, numeric (00..12).
%y = Year, numeric (two digits).
PHP Format
z = The day of the year starting from 0 (0 through 365).
m = Numeric representation of a month, with leading zeros (01 through 12).
y = A two digit representation of a year (Examples: 99 or 03).
MySQL Query
SELECT FROM_UNIXTIME(1357018200, '%j-%m-%y');
-> 366-12-12
PHP Code
echo date('z-m-y', 1357018200);
-> 0-01-13
Any help would be greatly appreciated, thanks for your time. :)
Other Information
MySQL Version: 5.5.23
MySQL system_time_zone: CDT
MySQL time_zone: SYSTEM
PHP date_default_timezone_get: America/Chicago (CDT)
Your PHP and MySQL aren't agreeing on the time. Using the time converter at:
http://www.4webhelp.net/us/timestamp.php?action=stamp&stamp=1357018200&timezone=-6
gives the result "Monday, December 31st 2012, 23:30:00 (GMT -6)" so your PHP is giving the wrong result. Although you've given the timezone that PHP is running in, can you double check by running:
date_default_timezone_set ("America/Chicago");
echo date('z-m-y', 1357018200)."\r\n";
Which should give "365-12-12".
I guess it's possible either something is setting the timezone incorrectly somewhere else or possibly that "America/Chicago (CDT)" is an old setting in your php.ini file from a previous version of PHP.
Looking at the list of allowed timezone values from http://php.net/manual/en/timezones.america.php there is no "America/Chicago (CDT)" listed, so you should figure out where it's getting set to that bogus value as it may cause other issues.
Once you've got your timezone issues sorted out, the answer to your actual question is:
function sqlStyleDate($timestamp){
$dayOfYear = date("z", $timestamp) + 1;
$year = date("y", $timestamp);
$month = date("n", $timestamp);
$result = "$dayOfYear-$year-$month";
return $result;
}
echo sqlStyleDate(1357018200)."\r\n";
That will convert PHPs 0-365 day of year, to be the same as MySQL's 1-366 day of year.

PHP Date / GMT Weirdness

Either I'm losing my mind, or I've not got the faintest idea what I'm doing. I'm leaning towards the latter.
I'm trying to convert this: 1316826000, which I'm pretty confident should be Sat, 24 Sep 2011 01:00:00 GMT
http://www.onlineconversion.com/unix_time.htm confirms this.
http://www.unixtimestamp.com/index.php tells me 09 / 23 / 11 # 8:00:00pm EST, so far so good. I happen to be in EST, this is the result I'd like to get back from PHP.
When I do date('l, M d, Y, h:ia', $iTime), I get: Friday, Sep 23, 2011, 12:00am, a full 20 hours off.
I've confirmed the server's time is correct using date('c'). date('c') output is: 2012-05-19T03:19:20+00:00. The server is in the central time zone, where it is currently 10:20pm. May 18.
echo date_default_timezone_get() outputs "GMT" (set somewhere else in the script using date_default_timezone_set('GMT'))
What am I missing? Nothing I've read so far can explain how I'm getting a result 20 hours behind what it should be. Were it an hour fast or slow, I could at least wrap my head around it being some sort of DST idiotry, but 20? Crazyness! Thanks for reading!
Check what your php.ini says for date.timezone.
In unix it is usually here: /etc/php.ini
Then use a proper timezone recognized by PHP:
http://www.php.net/manual/en/timezones.php
date.timezone = 'America/New_York'
Then reload your web server.
Unix time just means the number of seconds since epoch. Has nothing to do with timezones. Timezones simply add or subtract 1 hour (3600 seconds) from the unix time for each zone you move away from GMT.
An example:
$userTimezone = new DateTimeZone('America/New_York');
$gmtTimezone = new DateTimeZone('GMT');
$myDateTime = new DateTime('2014-01-22 11:44', $gmtTimezone);
$offset = $userTimezone->getOffset($myDateTime);
echo $offset;
That will output: -14400 or 4 hours. Which is the difference between New York and GMT
Using some Java code with the Joda-Time 2.3 library, as I don't know PHP…
long m = 1316826000L;
DateTime dateTimeUtc = new DateTime( m * 1000L, DateTimeZone.UTC );
DateTime dateTimeNewYork = dateTimeUtc.toDateTime( DateTimeZone.forID( "America/New_York" ) );
System.out.println( "dateTimeUtc: " + dateTimeUtc );
System.out.println( "dateTimeNewYork: " + dateTimeNewYork );
I can tell you that 1316826000 seconds from the beginning of 1970 UTC/GMT (Unix Epoch) is…
dateTimeUtc: 2011-09-24T01:00:00.000Z
dateTimeNewYork: 2011-09-23T21:00:00.000-04:00
So, as the commenter stated, it would be 8 PM in EST but EST was not in effect on that day. DST (Daylight Saving Time) (idiocy, as you correctly noted) was in effect until November 9 of that year (2011). So the time of day is pushed forward one hour, to 9 PM.
In GMT/UTC, that means 1 AM in the morning of the next day.
Standard time in east coast US is 5 hours behind UTC/GMT. With DST it is 4 hours behind UTC/GMT (one hour closer).
Where you got confused:
Your time format/conversion in incorrect.I can't help with that as I don't know PHP.
You should be using a competent date-time library for this kind of work.Date-time work is complicated, tricky, confusing, and error-prone.This question discusses possibilities of Joda-Time (for Java) sorts of libraries for PHP.
You used three-letter time zone codes. Avoid these.Those codes are neither standardized nor unique -- there are common duplicates. Instead, use proper time zone names. In your case of east coast US, "America/New_York". Furthermore, in this case you confused the time zone area and rules (east coast US) with a particular application of those rules (EST). Saying "America/New_York" means "whatever time zone rules were in effect on that date, whereas saying "EST" (if interpreted to mean Eastern Standard Time in US) means "UTC-05:00". So either (a) use a time zone name such as "America/New_York", or (b) use a specific offset such as "-05:00".

Understanding date processing with strtotime

I'm trying to get my head round someone else's code which they've written for handling the dates of when news stories are published. The problem has come up because they are using this line -
$date = strtotime("midnight", strtotime($dateString));
to process a date selected using a jquery calendar widget. This works fine for future dates, but when you try to use a date which is in the previous calendar year, it uses the current year instead. I think this is due to "midnight" finding the closest instance of the selected day and month.
I could remove the "midnight", but I'm not sure what the repercussions of this would be - is there a reason that the midnight could be there?
EDIT: this is the full block of code which handles the date. The date contains the time, which allows the user to publish an item at a specific time.
$array['display_date'] = '24 October, 2011 17:30';
$string = $array['display_date'];
$dateString = substr($string, 0, -5);
$timeArray = explode(':', substr($string, -5));
$hours_in_secs = 60 * 60 * $timeArray[0];
$mins_in_secs = $timeArray[1];
$date = strtotime("midnight", strtotime($dateString));
$timestamp = $date + $hours_in_secs + $mins_in_secs;
//assign timestamp to validation array
$array['display_date'] = $timestamp;
echo $array['display_date']; // Output = 1351094430 (Oct 24 2012 17:00:30)
This really depends on what $dateString contains. Assuming your jQuery widget delivered the time portion as well, your colleague likely wanted to remove the time portion. Compare the following:
echo date(DATE_ATOM, strtotime('2010-10-01 17:32:00'));
// 2010-10-01T17:32:00+02:00
echo date(DATE_ATOM, strtotime("midnight", strtotime('2010-10-01 17:32:00')));
// 2010-10-01T00:00:00+02:00
If your widget doesnt return the time portion, I dont see any reason for setting the date to midnight, because it will be midnight automatically:
echo date(DATE_ATOM, strtotime('2010-10-01'));
// 2010-10-01T00:00:00+02:00
Note that all these are dates in the past and they will result in the given year in the past, not the current year like you say. If they do in your code, the cause must be somewhere else.
Will there be repercussions when you change the code? We cannot know. This is just one line of code and we have no idea of any context. Your unit-tests should tell you when something breaks when you change code.
EDIT after update
The codeblock you show makes no sense whatsoever. Ask the guy who wrote it what it is supposed to do. Not only will it falsely return the current year for past years, but it will also give incorrect results for the minutes, e.g.
24 March, 2010 17:30 will be 2012-03-24T17:00:30+01:00
I assume this was an attempt at turning 24 March, 2010 17:30 into a valid timestamp, which is in a format strtotime does not recognize. But the approach is broken. When you are on PHP5.3 use
$dt = DateTime::createFromFormat('d F, Y H:i', '24 March, 2010 17:30');
echo $dt->format(DATE_ATOM); // 2010-03-24T17:30:00+01:00
If you are not on 5.3 yet, go through https://stackoverflow.com/search?q=createFromFormat+php for alternate solutions. There is a couple in there.

Timestamp Troubles

I have a snippet of code where I want to show the date and time for every time a client uses a discount card. Clients can not have more than two entries per card. However, when I try to display the two entries with the appropriate formatting only the older timestamp formats properly. Code below:
Last Used:
<?php
$timestamp = mysql_to_unix($row->trans_date); //MySql Time stamp 2011-05-31 12:49:59
date_default_timezone_set('America/Chicago'); //Push timestamp ahead 2 hours
$lastuse = date('F j, Y # g:i A', $timestamp); //format date
echo $lastuse;
?>
<?php endforeach; ?>
I have two timestamps coming in 1306871399 and 1306864204. The first stamp successfully processes as May 31, 2011 # 2:49 PM, but the second comes out May 31, 2011 # 12:50 PM.
I am not understanding why only one of the timestamps are being processed. Your feedback is appreciated.
1306871399
- 1306864204
------------
= 7195
7195 seconds = 1hr 59 minutes 55 seconds
May 31/2:49pm -> May31/12:50pm is about 1hr 59 minutes apart
So what's the problem?
You should format your timestamp values for user-display at the MySQL level, instead of using PHP to format them. That way, you don't have to worry about what timezone your PHP server is on (your reference to the Chicago timezone). Try using the MySQL Date Format function to return a MySQL formatted timestamp as a string you can display...
My thinking is that the older timestamp is not being passed through the timezone push, as it is 2 hours behind. Make sure your code is running both values through it.
If that's not it.. has your hosting provider changed recently? Server-time vs. Local-time could be an issue?

Categories