who can really reproduce this? When only using smart clients?
I can get the server for a moment to go to UTC:
And that is when it downloads the first client after an upgrade
Because that is what Pack200 does so it seems, it wants to pack in the UTC timezone
But it will set it back
So if i clean:
application_server\server\work\Catalina\localhost\lib
(or update/clean install of servoy itself)
and i open the admin pages (in one browser tab)
and i open a client that starts loading (in another)
When i refresh the admin pages i see the time zone toggling between CEST and UTC… at the moment pack200 is doing its packing.
But when the client is done it is on CEST again. So this should only happen on the first client that is loaded. (that takes care of all the packing)
Can some get this timezone shift with a default install of servoy? So without any 3th party plugins?
i have some stuff that i changed, and placed some checking around the pack200 code to be sure thats not the one that is keeping UTC timezone after it is done.
And i fixed another place that could be related with webclients. But what i find strange is that it is always to UTC…
What i find strange that now it is suddenly get reported over i think all versions (3.5 to 5)
The thing is that many also updated all the 3th party plugins to the latest because of java 6 update.
I just checked throughout all our code for setDefault() on TimeZone class and we did that in 1 place on the server (but this was already for a long time) and i improved that a bit.
I was having this problem today (server reverting to UTC time) on a fresh install of 4.1.7 Servoy Server on mac OSX. I discovered that there was no default timezone property in the servoy.properties file, and no default locale. I added these and now it seems to be working, though I just made the change 3 hours ago.
On the admin console I set locale.default to ‘en, US,’ <— yes there’s a comma at the end
and I added this to the end of the servoy.properties file:
“timezone.default=America/Los_Angeles” <— you’d have to look up the correct wording for your timezone. You can find the list by opening a smart client and going to Edit>>Preferences>>Locale>>Timezone
It seems to me that it’s the locale.default setting that did the trick but I’m not positive.
Update: server stayed in the correct time zone for 6 hours but then reverted to UTC time again so the changes I made (see previous post) didn’t solve the problem. I’m filing a case.
noticed on 3.5.12 that some windows clients were saying appointment showed an hour early.
Ok in database.
Set the server setting to true.
Yesterday noticed that 5.13 on the same server writing or displaying the same date showed it 1 hour early, but 513 server setting was true.
Not updated to java 20 on the os x box yet.
When I switch the date setting to false in 513 it then works fine,
but these server versions are running on the same box but with seemingly different outcomes as the apps were being used on the same mac client machines and were reproduced across two separate machines.
we really need to see what is the common thing here.
For example our own servoy server where our shop (web) and our crm (smart) runs on and many more stuff never switches to UTC.
But there we dont use many 3th party plugins…
So everybody that has this behavior can you give us a list with the 3th party plugins you have to see if there is a common ground?
(and what is the java version of the server)
Adrian: Can you guess a bit what you where doing around the time the server did do the switch? If we could pin point the trigger that would be great.
David: what do you mean with date setting? (use.client.timezone?) If that is true then you shouldnt have a date problem in the clients even if the server switches from X to UTC.
that after updating to 3.5.12 we got calls from windows users saying that the dates of appointments had suddenly changed to one hour early (we are GMT BST.)
At this stage the use.client.timezone on the 3.5.12 servoy server, running on OS X 10.5.8 java 1.5 at the time (now 1.6 after working out that seperate issue!)
The app_start field in my DB was correct, but the client showed it an hour earlier.
SOLUTION: switch use.client.timezone to TRUE.
Yesterday my secretary was booking appointments using my booking system, which is in 5.13, in which the script takes the date from an already created available appointment, and pushes it into another appointment record with the case details. She said that she offered someone a 12.30 appointment on the phone, booked it, the appointment letter then said 11.30, and then the system displayed a date of 10.30. (the DB date was written as 11.30)
The settings on 5.1.3 were the same with use.client.timezone set to true, something that i think i did when i installed 5.13 a week or so ago having had the issue with 3.5.12 and having read the advice to use this setting.
My analysis of what was happening in 5.1.3 is therefore :
row 12345 had a datetime 2010-06-30 12:30:00
servoy reads that date, creates a new record and writes it out again. At this point the date gets written as 2010-06-30 11:30:00. The letters created all have 11.30 in them as well
My dashboard view puts the date into a tooltip and then displays it as 10.30, so it is doing exactly the same thing when it converts the date to text using the utlis.dateFormat to change the date to a string.
Switching the use.client.timezone to false on the 513 server fixes the issue. So at present if have it True in 3.5.12 and false in 5.13
that previous date was then inserted with the boolean to false?
If that is the case and the server and client where back then in a different timezone then yes that previous date will come out differently
for example with the property to false and the server and client in a +1 difference
client inserts 12:30
server sees this as 11:30 and inserts this.
(and if the client reads it in the server gets 11:30 from the db and it is converted to 12:30 on the client)
But then if you set the property to true when the client reads in that same date
the server gets 11:30, sees that it has to convert first and it will convert it so that the client also sees 11:30
So what that property does is that all clients no matter where they are will see exactly what the server sees.
This is the only way to really get dates stable across all clients
If you have this property to true then even if the server switches to another time zone (let say +2 now) it will still be ok.
Because the DB → Servoy server will make sure that the server still sees 11:30 (but now in +2 time zone) and the server now converts 11:30 in +2 to a client value so that it will see also 11:30 in its timezone.
You may be correct in saying that the available date may have been set with the server in the false mode and then changed to true with the update last week. So servoy sees more than the date i see in the datetime field?
The only thing is that both server and client machines have always been set to BST and are in the same timezone!
If this is the case how can i get all of these date back into sync with each other, so that i can set the timezone to true, because I think what you are saying is that now that the one adding the availability is set to true and the one doing the booking is set to false, to maybe compensate for these old dates, then i may get a similar problem with dates added after this setting has been made.
I had just thought that is a date in the DB said 2010-06-30 12:30:00 and both servoy servers (running on the same machine) had the client.timezone set to true then all would be well, but its not! as yesterday proved.
dpearce:
I had just thought that is a date in the DB said 2010-06-30 12:30:00 and both servoy servers (running on the same machine) had the client.timezone set to true then all would be well, but its not! as yesterday proved.
David
how do you know that is is 2010-06-30 12:30:00 ? Do you query that with a different tool? through a jdbc connection? (for example sql explorer plugin in servoy developer)
But you could try it out very easily if you want, just setup a server and set it in a timezone, then startup a smart client and set that up in a completely different timezone and insert a date
Then look what the dates becomes in the database if you have that property to false or true
(and look what the date becomes in the client if you move the client to a different timezone again)
I had the same issue last week with a 3.5.10 install with the client property time zone to false.
The weird thing was, that only after print-preview the datetimes showed out -1 hour…
I did’tn paid much attention (had not read this topic) restarted the server and everything was fine again…
No it’s not reproducable, I asked internally here, and it has happened two times now (in abut 1 year).
The last time I saw it myself en fixed it by restarting the server, without looking any further… sorry.
EDIT: it only happened on clients on our terminal server, which usally ALWAYS open, and never shut down…
maybe this is related.
I am querying the data directly using Sequel Pro on a mac.
The date is 11.30 in the database now, but shows up in 5.13 as 10.30 when put into a tooltip using the util.dateFormat.
This corrects itself when you switch the client.timezone to false.
Both the client machine and server are set to the same timezone and the same time. I can check whether this is reproducible by switching the server back to client.timezone = true and looking at the screen again. I will see if i can do some screen shots.
mboegem:
One thing I changed is ‘i18n.setLocale()’ command.
setting the locale doesnt affect timezone’s thats a different thing.
Besides calling setLocale on the i18n node sets the locale of that specific web client not the default locale in the whole server.
dpearce:
I am querying the data directly using Sequel Pro on a mac.
The date is 11.30 in the database now, but shows up in 5.13 as 10.30 when put into a tooltip using the util.dateFormat.
This corrects itself when you switch the client.timezone to false.
Both the client machine and server are set to the same timezone and the same time. I can check whether this is reproducible by switching the server back to client.timezone = true and looking at the screen again. I will see if i can do some screen shots.
David
in what time zone is the Mac where you run Sequel Pro on?
If you insert a date in a Smart client thats has the default timezone of that mac
and then read it back in in Sequel Pro do you see the same date?
And if you then play with timezone’s for the smart client or the server what happens then?
I switched it back to true, restarted the server and client and guess what. The cases that showed the date an hour wrong yesterday before switching to false, are now showing OK!!!
So the issue doesnt seem to be reproducible, but i saw it with my own eyes on two separate client machines!
I have told the offices to be vigiliant, left the client.timezone on true and we will see what happens.
Dates are hard enough without ghosts in my server!!!
jcompagner:
we really need to see what is the common thing here.
For example our own servoy server where our shop (web) and our crm (smart) runs on and many more stuff never switches to UTC.
But there we dont use many 3th party plugins…
So everybody that has this behavior can you give us a list with the 3th party plugins you have to see if there is a common ground?
(and what is the java version of the server)
Adrian: Can you guess a bit what you where doing around the time the server did do the switch? If we could pin point the trigger that would be great.
David: what do you mean with date setting? (use.client.timezone?) If that is true then you shouldnt have a date problem in the clients even if the server switches from X to UTC.
This started happening when my client did a fresh install of 4.1.7 on his Mac OSX server running the latest java 1.6 update 19. The third party plugins he uses are:
log4j.jar from Dr. Maison (plugin)
charting beans from Object Planet - chart.jar, chart.ext.jar, chartServer.jar (beans)
We are continuing to monitor the server - so far it has behaved ok for 16 hours.