Zeruell / ppx-raidplaner

Automatically exported from code.google.com/p/ppx-raidplaner
0 stars 0 forks source link

Increase automated to modify a raid on "apply changes" button for a raid #13

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.Updated a raid
2.The start time and stop time increase with +1 hour with the button "apply 
changes". 

What is the expected output? What do you see instead?

Increase automated with +1 hours on each clic button "apply changes"

What version of the product are you using? On what operating system?

latest (093)

Please provide any additional information below.

Original issue reported on code.google.com by pixcontr...@gmail.com on 27 Dec 2011 at 5:56

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I will have a look on the issue this weekend (March 3/4).

Original comment by arne.cl...@gmail.com on 28 Feb 2012 at 7:26

GoogleCodeExporter commented 9 years ago
I could not reproduce this on my local system, but I guess it could be an issue 
with PHP's mktime function.
To check this I need additional infos about the server:

- Which PHP Version do you use?
- What timezone does the server use?

To check this, please have a look at phpinfo().
I need the PHP version (displayed at the top of the page) and the"Default 
timezone" entry in the "Date" section (e.g. "Default timezone: Europe/Berlin").

Original comment by arne.cl...@gmail.com on 3 Mar 2012 at 9:54

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Thx for your response. 

It's a great code and beautiful effect.

X-Powered-By PHP/5.3.8
(UTC+01:00) Bruxelles, Copenhague, Madrid, Paris

Original comment by pixcontr...@gmail.com on 7 Mar 2012 at 2:04

GoogleCodeExporter commented 9 years ago
Thx for the compliment and the reply :)
Sadly the data you provided does not look like its what I initially thought the 
problem could be.
I guess I will look into this issue next weekend (as I already mentioned on 
google+ my time on this weekend is already packed with other things).

Original comment by arne.cl...@gmail.com on 8 Mar 2012 at 10:42

GoogleCodeExporter commented 9 years ago

Original comment by arne.cl...@gmail.com on 8 Mar 2012 at 10:43

GoogleCodeExporter commented 9 years ago
I could reproduce the bug and fixed it (parts of the fix are already in the 
trunk).

If your MySQL server runs at a different timezone setting than your web server, 
dates are converted to that timezone on "the way in" but were not converted 
back "on the way out".
The problem here is that I use unix timestamps to pass the date (FROM_UNIXTIME 
function in MySQL) but did not convert it back when reading the date (which 
would be using the UNIX_TIMESTAMP function).
I fixed this problem, which will be part of the 0.9.4 release.

You can check on the problem when calling the query "SELECT @@global.time_zone 
, @@session.time_zone" e.g. with phpMyAdmin.
If the result shows "system", there is most likely no problem (unless the 
server is located in another timezone than your webserver). If something else 
is shown (e.g. "+2:00") and this does *not* match your webserver's timezone 
(e.g. "+1:00" in your case), than you have the described problem.

Original comment by arne.cl...@gmail.com on 17 Mar 2012 at 11:25