date is one month off

[Tupsi]

Every sig you put into pathfinder is off by one month. For instance stuff you enter right now gets show as 14.02.2016 20:32

[sn0opy]

Is your server time even correct?

[Tupsi]

Is that a serious question? Of course it is. Wrong server time is usually of by hours if set to wrong time zones are completly off it not set at all, but NOT off by exactly one MONTH.

[sn0opy]

Check the system_signature table in the DB if the date is also off by 1 month. I just set it up yesterday and it works for me.

How did you add the signature? Manually or or through the signature reader from you clipboard?

[Tupsi]

they are correctly dated in the database, strange:

2016-03-15 20:31:28 2016-03-15 20:34:18

but when I mouseover the ? in the sig row the mouseover shows the 15.02.2016 19:34, which is correct as its -1 to CET.

Server is set to CET, date shows:
date
Tue Mar 15 20:34:47 CET 2016

I tried both adding manuelly and c&p stuff.

Dont get it. Where does even the german date formating comes from? Does the IGB pulls that out of my windows installation? Can it even do that? Because ingame if you hover over the time in the lower left corner you see the date listed as 2016.03.15.

[exodus4d]

Could you fix it?

If not, please consider the following:

• Pathfinder should always display and store EVE Time time stamps.
• The timezone (used by any PHP script) can be defined in config.ini (default: UTC - should be fine)
• The timezone (used by the DB) is automatically set to UTC for the current session (database.php L.53)
• The current Server time can be checked on the setup page (http://[YOUR_DOMAIN]/setup)
• The German date format in the Sig-table is my fault :( ( Ill change the display format )

[Tupsi]

no I could not. Frankly I have no idea how this can happen in the first place as we are talking -1 month instead of the usual +-1 hour thing. Just created a sig and it says 10.03.2016. Server time is

date

Sun Apr 10 19:35:27 CEST 2016

the time itself is fine (-2 currently to germany as eve itself is), its the month which gives me headaches, NOT the hours.

as you can see its correct in the database, although it is NOT in line with your first statement. the 19 hours is german time here currently and not eve time. So if you are saying the dates in the db should always be eve time, there is something wrong there as well (as in the db it should 17 ).

[Tupsi]

ok, I just added another sig from ingame to verify (up this one came from Firefox), but its still saying 19 for the hour. So you are in fact not writing eve time, but server time instead. So maybe this is the problem, that my server is set to CEST instead of UTC?

I don't have any real clue in php, just general programming, but isn't the line you posted from database.php only using the system timezone (which in my case is CEST) and you would have to do it differently if you always want UTC?
found this: http://stackoverflow.com/questions/930900/how-to-set-time-zone-of-mysql
which implies if the my.cnf uses system time and you set it to use system time as well and the server is not set to UTC you are NOT writing the entries in eve time, but in server time which could be anything.

[Tupsi]

ok, I am confused now. For testing and to risk the wrath of Bob I changed the timezone of the server to UTC (dont ask my why I set it to Berlin in the first place please) which it should have be from the beginning of time anyway. All entries in the db now show -2 hours which means eve time, so whatever cool mysql wizz is going on there, it can apparently survive a dpkg-reconfigure tzdata.

While the hours now show eve time, the month is STILL one month off, which does not make sense at all. (In the browser only as you can see in the screenshots, the db has april in it as it should.)

[exodus4d]

Problem solved :)

it was in fact a client-side (javascript) bug in one of the "date convert" function.
The new Date(); javascript Class constructor requires the current month as constructor param. (util.js L1682)
The index of January = 1, February = 2,...

The getUTCMonth(); return month indexes, started by 0: January = 0, February = 1,...

Therefore we have to add +1 for each month.