Today I have discovered a strange behaviour in my solution: some dates are displayed with 1 day less.
Here is what is present in the database: [attachment=1]Capture2.PNG[/attachment]
Here is what is displayed in the solution: [attachment=0]Capture1.PNG[/attachment]
As you can see some dates are the same and others are different. The highlighted records is quite interesting because only the From date is incorrect
Data is directly displayed from the database, there is no calculation made.
This is on our production server (Servoy 5.1.0) . On developer (5.1.0) it works fine (dates are well displayed). On our test server (5.1.1) it works fine as well.
The only difference I have noticed is that on the test server and Developer the time is in BST (correct current time) while on the production server has UTC time (one hour less). But on all of them have servoy.use.client.timezone is set to True. So their might be a link with the date minus 1 day and the time minus 1 hour, as the time in the dates is 00H00
But if it’s that, why not doing it for all dates?!
We just had to restart the server which was up for several days. The time became BST and the date came back to normal.
So that’s definitely a bug in my opinion. You shouldn’t have to restart the server for it to pickup the right time
I’m replying to the case update of Johan here, as I don’t know how to reply on the CRM system.
Johan:
so to get the complete picture
You production server kept running over a weekend that had a DST change right?
Yes.
Johan:
Problem is that this seems to be deepily into the java virtual machine. It seems that TimeZone instances we ask from the server are not adjusted on the fly when we ask it before and after a dst change.
(at least that is now my guess)
If you are right, this is a big weakness of the JVM.
It means that any application server using the JVM and only rebooting once a week can potentially get the same problem that we had?!
i am looking into it, the thing is that there is another option
new clients that came in after the dst change also show those problems?
Because then maybe we cache the client time zone incorrectly on the server. But then only clients that keep connected on the server over a DST change should have this problem
new clients that are connection after the dst change happened should not have this problem then.
jcompagner:
new clients that came in after the dst change also show those problems?
Yes. People are connecting daily. But they were not really new in the sens that they already connected before and didn’t have a clean empty cache. Maybe the old timezone still was in their cache?
no that cant be it, a new client is completely fresh with its current timezone info.
This is extremely hard to reproduce or to test. And looking in the code i have currently no idea where this behavior exactly is in.
TimeZone information doesnt really change as far as i can see before the DST and after… (it just holds the info)
And if new clients do see the problem (and maybe old clients where not seeing it, this would also be go to know, but not really easy to reproduce)
then it has to be something on the server.
Unfortunately I can’t give you more information than the details in my 1st post and the fact that every client are connecting/disconnecting everyday and very often several times a day. However we never clear their cache (except when they have issues specific to them).
But what is sure is, that before restarting the server it had UTC timezone and after the reboot BST. And I’m 99% sure nobody connected yet when I have checked after the reboot.
Anyway, we will wait till winter time to check it again
I restarted our Servoy 3.5.12 server late yesterday and now we are having problems with the times and dates of appointments in our diary (IT2BeCalendar) and in Servoy list views. We have ‘servoy.use.client.timezone’ false, actually never noticed that setting before. And clients set to Europe/London. Quick-fixed this yesterday by subtracting one hour from appointments after 28 March. But our list views are still incorrect.
When I fire the actual query directly on the PostgreSQL database it works as expected. It looks like Servoy is shifting timestamp parameters before sending them to the backend database. If I relaunch client in GMT timezone, the list looks as expected.
you should have this servoy.use.client.timezone set to true
Especially when you deploy for the first time and dont have inserted any dates yet in the database.
I think you hit the problem that the server shifted to UTC (you can see this on the admin pages) when it should be in Europa/London (thats your 1 hour difference)
If you had you have the property on true you wouldnt notice that the server has a different timezone then before.
But then all your dates should be inserted when the clients and the server where in the same timezone else there you could see a bit of difference.
I kicked all the users out for a minute over the lunch break and set servoy.use.client.timezone set to true
and this has fixed the problem. I’m a little confused, this system has been running for about 4 years and we
have never had this problem before.
I did start a Developer on the server machine by accident and I wonder if it has somehow mangled the prefs file for the server…
dont know
keep monitoring in what time zone the server is in
If that suddenly changes again then there is something in servoy that does that and that should be fixed.
jcompagner:
you should have this servoy.use.client.timezone set to true
Especially when you deploy for the first time and dont have inserted any dates yet in the database.
Johan, we are in the situation, that we have allready have a solution in production, with this setting to false (in Servoy 3 and < we did’nt had this property)
What should we do, if we want to convert to servoy.use.client.timezone set to true
