timezone/locale differences between developer and client

Classic Servoy
1

Hi all,

I have a local machine set up for developing in the America/Los Angeles timezone/locale, while my servoy server/repository and database are in the America/New York timezone/locale (that’s a difference of 3 hours).

In creating my solution, I’ve noticed that timestamps were not matching up between viewing/using a solution on the developer, and doing the same in the client. Most notably, timestamps sent to the server while using the developer were using my local machine’s time (in America/Los Angeles), while the server was not translating that time to it’s local time. Conversely, while using the client, timestamps were showing the correct time for America/Los Angeles, and correctly stamping in the America/NY timezone.

I have both my developer and client locales set to America/Los Angeles, and I’m wondering why the developer does not appear to pay attention to time zone differences between itself and the server it is talking to. One thing of note: application.getServerTimeStamp() in my debugger sends back the local time on my machine, and not the server (repository/database/app server) time.

Is this normal behavior? It appears to me that Servoy only pays attention to client locale, and not developer locale.

Thanks,
Aron

2

Hi Aron,

When you use Developer you in fact also have an instance of the Server running (in a special mode). This server is the one that is connected to your back-end database. I assume you setup the time stamps to use the server time. Well in Developers case that will be your machine.
When you use Client then it will use the Server time correctly because that is running in NY and the Client Locale settings calculate them nicely back to it’s time zone.

So that’s the explanation. Now the warning.

When you use Servoy Sequences they are stored in the Server. When you connect with multiple Servers, like you do now when using Server and Developer, on the same back-end database you can (and most like WILL) end up with sequences being out of sync and users will get errors when creating records because PK’s are already used (and have to be unique).
When you use DB identities or DB sequences you don’t have this issue.
But in all cases by using 2 servers you don’t have the data-broadcasting of the changes to the other clients since the other server doesn’t have a clue what data you touched/added.

Also I am not sure if you do this already but it’s also highly recommended to work with a separate development repository (on your development machine) and a deployment repository (on your server).
You just export your solution and import it in Server using the admin pages. Only this way you are ensured that your ongoing development don’t have any effect on the live solution (and it’s users).

Hope this helps.

3

Robert-

Thanks for the detailed reply!

I actually don’t use a separate repository for development and deployment – in fact, I also use the same database for development and deployment. Probably not the best idea, I know… However, I haven’t encountered any problems (so far) with using the same repository for development and deployment. Is there a reason why this is not recommended?

I’m planning on switching over to using DB idents, though, which appears to solve the problems associated with using Servoy sequences.

Thanks again for all the info-
Aron

4

Do set in adminpage:
servoy.use.client.timezone to true

In the 3.5 branch we cannot set this to true by default, since it changes the bahaviour of date storage and makes old dates differ when switched(in Servoy 4.0 we will enable this be default)

5

My understanding is that I would want all of the timestamps to be synchronized to the server time, and have the client make the necessary calculation to display the correct time based on the locale. If I set servoy.use.client.timezone to true, won’t all the timestamps then have the client’s timezone, rather than the server’s timezone? It seems that this would cause trouble because then the client will try to calculate an offset based off of the wrong initial time zone.

For example, it’s 12pm at the server, and 9am at the client (3 hours behind the server locale). If servoy.use.client.timezone is true, then a timestamp will be set as 9am. Then, when a client logs in that’s 3 hours behind the server locale, it will try and recalculate the time as 6am, which is incorrect.

This is why I keep servoy.use.client.timezone to false… am I understanding this behavior correctly?

6

Its exactly the other way around as you thinking.
The information shown for the property on the admin page in 4.0 read ```
“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 dates/times in all clients (regardless of there timezone)”

We will show this info as well for upcomming 3.5.x releases.
7 
"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 dates/times in all clients (regardless of there timezone)"

That’s odd, because the behavior I get in 3.5.5 with servoy.use.client.timezone set to false is the same as your description of having it set as true. When it’s set to true, timestamps IN THE DATABASE reflect the client’s time, but the client is in the Pacific Time Zone while the database is in the Eastern Time Zone (a three hour difference). This means timestamps are Pacific Time, which is not where the database is. So, when a client logs into the solution they will have their times incorrectly shifted, since the database time is off.

Maybe I’m overcomplicating the issue, but everything seems to work fine (other than when I’m in Developer). Have things changed in 4.0?

8

Setting that property to true will result in that the time a client types in is stored as that time in the database

So if a client types in:

01-01-2008 00:00

Then that exact time is stored like that in the database, we have to do it that way because else we never get things right otherwise. The database driver will do that conversion anyway for us. Also if rich and web clients where getting out of sync.

What you as a developer should do is set the value to true and then also store the timezone as a column besides that date. So that you know what time zone that date is for. This has to be done that way to be completely correct.

For example with the above date… If you live in another timezone then the one that entered that date. You suddenly see 31-12-2008 23:00 this is not what you want most of the time, sometimes you do and then this auto conversion works but when you dont want it and you have the property on false. You will never get it correct whatever you try…

so set the property to true and if you work with different time zone’s and it is important that people know that the time portion is for a specific time in a specific time zone you have to store an extra value besides the date column.

What you describe here:

For example, it’s 12pm at the server, and 9am at the client (3 hours behind the server locale). If servoy.use.client.timezone is true, then a timestamp will be set as 9am. Then, when a client logs in that’s 3 hours behind the server locale, it will try and recalculate the time as 6am, which is incorrect.

If you have the timezone to true. Then it shouldnt recalculate it and the time should be 6am… What you should see is what the other client Exactly typed in… if this isnt the case then you encountered a bug.

9

there where some problems with the webclient. That one didnt follow that same behavior as the rich client this will be fixed in the next release of 3.5 and 4.0

10

I apologize for how long this posting is - I felt it was the only way to state my questions clearly.

I am working with timestamps originating from different timezones and I sometimes need to display these timestamps in the local time for originating timezone, regardless of the user’s timezone. So for example for an event that took place at 15:00 in New York (GMT-5), I need to always display 15:00, even if the user looking at the timestamp is in Los Angeles (GMT-8).

I have servoy.use.client.time.zone set to true, and I have followed Johan Compagner’s advice of storing the event’s local timezone (-5 in the above example) in a separate column and everything is working fine (in the rich client - haven’t tried in web client yet). But I am not doing anything with the ‘locale default timezone’ preference in the client. I would rather my users not have to mess with that if possible. I am relying exclusively on the timezone setting in the client’s OS, and so far it’s working.

My questions are:

1 - What is the purpose of the ‘locale default timezone’ preference given that Servoy is already getting the timezone from the OS?

2 - How is this preference being set initially? In my case it is initially setting itself to Americas/Los Angeles, which matches the server’s timezone, even if the OS of the client is set for a different timezone. If I leave it alone, everything above works fine. If I set it to Americas/New York then in the example above instead of displaying 15:00 it displays 18:00.

Specifically, to display a stored timestamp in local time I am doing this:

On solution startup I get the user’s timezone by doing this:

var globals.userTimeZone = new Date().getTimeZoneOffset()
// returns the GMT offset of the client's machine, based on the timezone setting in the client OS. 
// In the example above, with the user in Los Angeles, it returns 8.

Then each time I need to display a timestamp in the event’s local time I do this:

clc_timestamp_local = timestamp + (globals.userTimeZone + local_time_GMT_offset)*globals.constant_milliseconds_per_hour

My logic is as follows:

By adding globals.userTimeZone to my stored timestamp, I am converting the DISPLAYED timestamp to the GMT-0 timezone.

Then I add the local_time_GMT_offset which I stored in the db alongside the timestamp. In the above example that would be -5. This converts the DISPLAYED timestamp to the New York (GMT-5) timezone.

Thanks for your help.

11

Perhaps my previous posting was too long and involved and that’s why I haven’t gotten any responses. Let me try just asking this:

What is the purpose of the ‘locale default timezone’ preference in the rich client, given that the client already gets the client machine’s timezone from the OS?

Thanks.

12

So that you can override it in your application if you dont like what the os is telling you (or the os is configured wrong)
or you are currently on the move on your laptop and the os doesnt change but you want the servoy app to follow the right times.

13

about your second question
The default is get from the client OS. So that is what the client OS is giving us.

If you have that server property enabled (to true) and If you change it in a client and you restart the client.
then the dates should still be just exactly what you typed in the other timezone. So if you typed 15:00 in timezone X then after change/restart it should also display 15:00 in timezone Y

14

I am finding that on WinXP under JRE 1.6 (product 1.6.0_11) the Servoy smart client is no longer picking up its timezone from the OS. It seems to think its in the server’s timezone. When I roll back to JRE 1.5 it works fine.

Does not seem to be a problem on Mac OS.

Anyone else having this issue?