Hi,
I am encountering this weird issue when running an application build for Servoy 3.5.7’s web client:
I have a date field: format dd-mm-yyyy, and a date dataprovider: 1-05-1953. The same browser (including version), accessing the application from 2 different machines displays this date differently:
Diana
check if both machines are on the same timezone!
(I think not )
Hi Harjo,
The servoy.use.client.timezone property is set to “false” in servoy-admin. To make sure you understand what i mean: there are 2 clients of the same application open: one on my PC,one from a remote server. Even if the dataprovider is 1-05-1953, the remote browser displays 30-04-1953. The same version of browser dispalys the data correct: 1-05-1953 on my local PC. Is there a setting that causes this to happen?
Diana
yes, still check both timezones of both PC’s
are they the same?
(if it is window, doubleclick in the rightbottom corner on the clock, choose the second tab)
ahh… it’s webclient!!
hmmm that is weird,
They are different indeed:
local: GMT+2
remote: GMT+1
Is there a way not to take this in consideration when displaying the date?
Diana
oke, than it IS working the same as in a smart-client.
a date like 12-01-2009 00:00 set in GMT+2 will present like: 11-01-2009 23:00 in GMT+1 (this is standard behaviour)
do not exactly know, how you can prevent this.
look here: http://forum.servoy.com/viewtopic.php?t=10806
Timezone Behavior Change
Important behavior change: by default, the property “servoy.use.client.timezone” is set to true.Property description:
When true the client timezone will be used to convert to the server/database timezone. It is highly recommended to use true as default to always see the correct/same dates/times in all clients (regardless of their timezone).
This fixed the problem.
Thanks a lot Harjo!
Diana
Hello,
Is it possible that setting servoy.use.client.timezone = true messes up the existing dates in the database?
(For records previously introduced from a place with time zone GMT+9: the dates now show one day less. For other time zones the dates are displayed correctly, I am confused…)
Diana
Hi Dianna,
no it doesnt mess up the data in the database. It just returns now a different end result.
Because it interpers the date now different at the server/client.
for example if you have that property to false:
Client in TimeZone X sends Date X (10:00) → send to server in TimeZone Z → Saves Date X as is (seen as 11:00 at the server)
Client in TimzeZone Y reads Date X and sees that date in its own time (12:00)
set the property to true:
Client in TimeZone X sends Date X (10:00) → send to server in TimeZone Z → Date saved converted so that it is also seen as 10:00 at the server
Client in TimzeZone Y reads Date X and sees again that date converted to its own time also at 10:00
So with that property to true, no matter where you are you will see the inserted time (so the toString() of the date is everywhere the same)
If you want to support multiply timezone’s then you have to store that besided the time column so that you know that 10:00 is really 10 at timezone X.
But now back to the question.
If you have dates inserted without the property. then read with the property it will do conversion so the Client in TimeZone X that sends the date with time: 10:00
but that time was at the servers timezone 11:00 then with the property suddenly on the client in TimeZone X will see that date as 11:00
(because the times are from the server on “stable”)
so it seems to be messed up for you yes. Because now the previous times are converted to always see the exact toString() the server sees.
Thank you very much for the clearings Johan!
If i understood correctly,the data seems to be “messed up” for me only for the dates introduced when property was on false. So from now on (property = true) the dates will always be the same: the ones on the server. Please correct me if I am wrong.
Diana
yes if the property is on true then where ever a date like “2009-15-06 10:30” is inserted from, what ever timezone
it will always come out exactly the same on what ever time zone you view it again in.
Thanks Johan!
So with that property to true, no matter where you are you will see the inserted time (so the toString() of the date is everywhere the same)
Hi,
I have the property on TRUE and yet there is an hour difference between what is in the database and what is displayed in the client for new created records, so records created with property set on TRUE. I posted the same issue in “Time displayed with different values in web and smart client”, because first I thought of it as a different issue…
I really need your help on this one,a wrong date is incorrect info displayed to the user and it has bad consequences…
Many thanks in advance!
Diana
how do you know what is in the database?
So you are saying with that property set to true.
If you insert a date in timezone X then read it back in in another client in timezone Y that client sees another time?
jcompagner:
set the property to true:
Client in TimeZone X sends Date X (10:00) → send to server in TimeZone Z → Date saved converted so that it is also seen as 10:00 at the server
Client in TimzeZone Y reads Date X and sees again that date converted to its own time also at 10:00
When servoy.use.client.timezone = true, the user time zone date and time is saved into the database when using application.getServerTimeStamp() even if the user is in another time zone then the server. Is this correct behaviour?
which servoy version are you talking about?
in 3.5 the server time will not be converted when going from the server to the client (and when you save it will) so this isnt really correct yes (the client doesnt really ‘see’ the server time)
in 4.1.1+ this is fixed then if you ask the server time and it is 10 oclock it will be “10:00” when arriving in the client
and when saved it will really be savend as “10:00” (even if the client time is “12:00”
jcompagner:
which servoy version are you talking about?
3.5.7
in 3.5 the server time will not be converted when going from the server to the client (and when you save it will) so this isnt really correct yes (the client doesnt really ‘see’ the server time)
Ergh… we try to track -method- execution duration time with users on different time zones. The log records contain now wrong start and end times…
in 4.1.1+ this is fixed then if you ask the server time and it is 10 oclock it will be “10:00” when arriving in the client
and when saved it will really be savend as “10:00” (even if the client time is “12:00”
Perfect. Thank you.
you want to track what exactly?
client side method execution time? why do you need to have a server time for that?
You want to track when the method did start? or how long it toke?