# Client Timezone sets improperly after server restart

**URL:** <https://forum.servoy.com/t/client-timezone-sets-improperly-after-server-restart/17920>\
**Category:** Classic Servoy\
**Created:** [April 23, 2014, 1:10pm UTC](https://forum.servoy.com/t/client-timezone-sets-improperly-after-server-restart/17920 "2014-04-23T13:10:08Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mmcmanus](https://avatars.discourse-cdn.com/v4/letter/m/a4c791/32.png) [@mmcmanus](https://forum.servoy.com/u/mmcmanus)\
**Post date:** [April 23, 2014, 1:10pm UTC](https://forum.servoy.com/t/client-timezone-sets-improperly-after-server-restart/17920/1 "2014-04-23T13:10:08Z")

</div>

I have looked around a bit for this issue including Java webstart Stuff. But have not found a fix or a good reason. Some clients have their timezone set to UTC when launched after we restart the Server. Only after a Server restart. If the client is inactive for a week after the restart, when they open again, the timezone might be UTC. Not every client. Only some. This includes some Windows users and MAc users. When the client restarts again, the timezone goes back to their normal. Forcing the timezone won’t work, since we have users in other timezones. I have tried setting the timezones on those users clients, but it does no stay. Has anyone else seen this and have any experience with it?

Its an issue for timestamps, which get set improperly when the time is UTC. And timestamps are kinda important for some things here.

We are running:  
Servoy version 6.1.6 -releaseNumber 1439  
JVM Information  
java.vm.name=Java HotSpot™ 64-Bit Server VM  
java.version=1.6.0\_35  
java.vm.info=mixed mode  
java.vm.vendor=Apple Inc.  
Operating System Information  
os.name=Mac OS X  
os.version=10.7.5  
os.arch=x86\_64

---

<div class="post-metadata">

**Author:** ![m.vanklink](https://avatars.discourse-cdn.com/v4/letter/m/d78d45/32.png) [@m.vanklink](https://forum.servoy.com/u/m.vanklink)\
**Post date:** [April 23, 2014, 1:44pm UTC](https://forum.servoy.com/t/client-timezone-sets-improperly-after-server-restart/17920/2 "2014-04-23T13:44:47Z")

</div>

Very interesting we have a similar problem that we cannot exactly address. We have a table that has an id of type servoy\_seq and a field log\_creation\_dt of type datetime. When a new record is created the field log\_creation\_dt is automatically filled using Auto Enter\>System Value\>creation server datetime.

Now we see in the database that **sometimes** the highest id-value does not have the newest log\_creation\_dt. It looks like this record was created using the wrong timezone and thus was placed two hours back (our difference with UTC).

How do you determine that these clients have their timezone set to UTC? Is application.getServerTimeStamp() different from application.getTimeStamp() in this case?

---

<div class="post-metadata">

**Author:** ![mmcmanus](https://avatars.discourse-cdn.com/v4/letter/m/a4c791/32.png) [@mmcmanus](https://forum.servoy.com/u/mmcmanus)\
**Post date:** [April 23, 2014, 5:06pm UTC](https://forum.servoy.com/t/client-timezone-sets-improperly-after-server-restart/17920/3 "2014-04-23T17:06:07Z")

</div>

The easiest way is to check in Server admin in the Clients tab. Double click on a client and it will give you the clients details, including the locale which specifies a timezone. You can also check in the client itself under preferences in the locale tab. You can change it there if you desire.

The two should be different if the locales are different.

---

<div class="post-metadata">

**Author:** ![jcompagner](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.servoy.com/jcompagner/32/4889_2.png) [@jcompagner](https://forum.servoy.com/u/jcompagner)\
**Post date:** [May 9, 2014, 2:34pm UTC](https://forum.servoy.com/t/client-timezone-sets-improperly-after-server-restart/17920/4 "2014-05-09T14:34:28Z")

</div>

what you have seems to be this:

[https://support.servoy.com/browse/SVY-4984](https://support.servoy.com/browse/SVY-4984)

thats a bug in the java/javawebstart. We created a workaround for that (included in 7.3 and also backported to 6.0.x)
