Date Issue

[robysimo09]

Hello

I have a server date issue.

I update my server to servoy 4.1.6 and after to 4.1.7.
I use java 1.6 update 20 and 1.6.06 in another server.

When the server start, the server date format is CEST ( first page of servoy admin page )
Below the server information:

Server Information
Servoy version 4.1.6 -build 689
Repository version 35 (f81064ba-81ed-4c8c-9d55-7f876b58f05f)
Current time: Tue May 11 14:25:46 CEST 2010

From a pc, I clear the java cache and launch the client. When the client start to download the application the server change date format in UTC format
Below the same Server information with UTC date:

Server Information
Servoy version 4.1.6 -build 689
Repository version 35 (f81064ba-81ed-4c8c-9d55-7f876b58f05f)
Current time: Tue May 11 12:31:22 UTC 2010

What is the problem? Is a servoy issue or java issue.
This happens after the upgrade to 4.1.6 or 4.1.7.

Thank you for help!
Bye
Roberto

[jcompagner]

so you didnt restart or change anything on the server
you only started a client and then the server changed its TimeZone?

[robysimo09]

Yes

If I restart the server the TimeZone is CEST.
But as soon as I start a client with cleared chache, the timezone change to UTC.

Roberto

[jcompagner]

you do start a smart client and not a webclient? (or a batch client on that server)

[robysimo09]

A smart client. Not with batch.
I can't try with web client.

Roberto

[robysimo09]

Hello

any news for the issue?

Thank you!
Roberto

[jcompagner]

because you only use smart clients and no web/headless or batch we cant see it right away
please create a case for this.

[Foobrother]

Isn't it because he's got the setting "servoy.use.client.timezone" set to true with smart client timezone different than server?
It shouldn't change the server timezone, should it?

[jcompagner]

no that cant be.
It could be possible that something changes for web/batch or headless clients, thats also what we look into. But smart clients shouldnt set the default timezone or locale on the server.

[Foobrother]

By the way, with my Summer Hours change issue, I have a Batch User running on the server

[robysimo09]

At the client launch, the timezone change 3-4 times from CEST to UTC and viceversa and at the end the format remain UTC.
Before the upgrade to servoy 4.1.6/7 this didn't happen.

Roberto

[robysimo09]

Opened Case 292685.

Roberto

[martinh]

I noticed same kind of issue.
Looks like since update to 4.1.6, because I didn't notice it before.

Now it is 11:06 (Brussels), but Servoy Admin Page shows following:

Server Information
Servoy version 4.1.6 -build 689
Repository version 35 (895d61ef-3255-446e-966d-f89399321361)
Current time: Wed May 19 09:06:51 UTC 2010
java.version=1.6.0_17-b04


The server has correct timezone and correct time. But all info in the (production) server (like client logged in) are shown 2 hours earlier now.
But on another server (development server) running also 4.1.6 with java update 17, the time is shown correctly.

Strange is that the Server Log, shows the correct time.

Capture.JPG (24.25 KiB) Viewed 9083 times

But Lock Info is showing wrong time:

Release this lock 1.1; locked by x (Servoy Web Client) at Wed May 19 09:13:57 UTC 2010

And for the Transaction Info the same.

So somehow there is a difference between the Lock Info time and the Log time ... strange

[jcompagner]

its not 2 hours earlier, its exactly the same time but then in UTC and brussels is UTC+2 at the moment.

So it is not that your time is wrong, that one is correct, its that sometimes it formats the date string with a UTC timezone and other times with CEST time zone..

[martinh]

its not 2 hours earlier, its exactly the same time but then in UTC and brussels is UTC+2 at the moment.

So it is not that your time is wrong, that one is correct, its that sometimes it formats the date string with a UTC timezone and other times with CEST time zone..

Technically it is not a wrong time, but for me from a visible perspective it shows wrong time.
I'm not looking at timezones. It must always show the time in the timezone that I expect.