March 13 2016 DateTime weirdness

[stevieontario]

probably a basic problem but I've been banging my head against it for an hour and a half.

 

I'm trying to combine date and hour strings from a .csv file into a MySQL datetime variable.

 

So 2 a.m. on March 13 2016 is proving a bit of a challenge:

$date = '13-Mar-16';
$hour = 2;
$startdate = $date.' '.$hour.':00:00';
$datehour = new Datetime($startdate);
$datehour = $datehour->format('Y-m-d H:i:s');
echo 'datehour is '.$datehour;

returns

 

 

datehour is 2016-03-13 03:00:00

 How did hour 02 become 03?

 

Also, change '13-Mar-16' to '13-Mar-15' and the above code will return hour 02, i.e. the "proper" hour.

 

Any idea what I'm doing wrong here?

[ginerjm]

Is this possibly affected by the change in when DST takes effect? The date of the annula change was modified in the last couple of years - could this affect your calculation?

[kicken]

Yes, this is due to daylight saving time.

Daylight saving time 2016 started at 2:00 AM on Sunday, March 13

 

For areas affected by DST there is no 2:00 to 2:59 am on that day. The time goes directly from 1:59:59am to 3:00:00am

Edited December 19, 2016 by kicken

[ginerjm]

Yeessss!

[stevieontario]

thanks to both of you -- well that would explain it. 

 

Now that puts two identical datetimes into my db (which is how I discovered the issue in the first place). The creator of the .csv cares not about DST -- they just give hourly data, hour 1 through hour 24.

 

I guess I have to figure out something involving  getOffset().

[Psycho]

You have to be very careful about any calculations during the changes due to daylight savings to guard against tearing a hole in the space time continuum.

 

 

thanks to both of you -- well that would explain it. 

 

Now that puts two identical datetimes into my db (which is how I discovered the issue in the first place). The creator of the .csv cares not about DST -- they just give hourly data, hour 1 through hour 24.

 

I guess I have to figure out something involving  getOffset().

 

That is why you would want to use a timestamp (not a datetime) field. A timestamp is the number of seconds since Dec. 1(?), 1970. The "date" you might see in the database is simply the extrapolation of that timestamp into a representative value based on the servers timezone setting. So, if you do have a timestamp from the data, you are good, else you have no way of knowing which record is for which hour when the clocks go back. Although, if there is one record per hour (or a set number) I suspect you may be able to assume the first record was the first hour and the second was from the hour after the clocks were set back.

Edited December 20, 2016 by Psycho

[stevieontario]

I never worry about that, I just use the built-in php function stc_tear_prevent()