Date Issue

[rafig]

Just to add my 2 pence worth (I'm in the UK), I have just noticed this strangeness happening at my biggest client.
I happened on a smart client on a table view (locked) with a column that was set to auto-enter the 'modified server datetime' (with another problem that the datetime did not change visibly unless you went off the form and back again, even though it did update the back-end correctly at the time of change...)
When I was looking into this, I noticed that the time was 1 hour behind local time (we are on BST [GMT+1]).
Server settings have not been changed, and times always used to be ok (I hope ), with servoy.use.client.timezone set to TRUE.
Server Admin page is showing time is now on UTC!
Server has not been restarted in over 26 days! (but I have asked IT to restart it on a weekly basis...)
I have not updated Servoy from 5.1.2 or Java from Java 6 Release 17 due to all the issues. (Although I have signed everything that wasn't signed)
Only 3rd-party plug-ins in use are Servoy's very old fmp.jar & the busy.jar plug-in.
I have uploaded MANY new releases to the solutions and also clients will have done lots of clearing of their Java caches as any time there is an issue here, that is what I have told them to do.
I will make sure I do a Server restart at the end of the day today and see if time goes back to BST.
I am attaching a screenshot showing Servoy Admin, along with some of the Server Properties file and also the server time.
Properties show that timezone is set.
When using my local developer, but talking to client back-end, times are set correctly (and auto-enter values change instantly) [My Servoy Admin shows BST]
Hope this helps in some way...

Looking forward to a resolution

Rafi

[jdcunha]

Hello all,

I had created a post last month viewtopic.php?f=8&t=14339, but Patrick suggested that the issue could be related to this post.

I tested the issue with the new build and the issue still persists.

Any suggestions on what setting I would need to enable/disable or do I need to wait for the new release?

Regards
James Dcunha

[jdcunha]

Hi,

We upgraded from Servoy 4.1.5 (jre 1.6 update 18) to Servoy 4.1.7 (jre 1.6 update 21).

We found that our time-entry times are all off. Our servoy server admin setting

Code: Select all

Server Information
Servoy version 4.1.7 -build 690
Repository version 35 (d95ac900-c03d-4f79-95d4-7340001da07e)
Current time: Mon Aug 09 12:35:28 UTC 2010
Uptime: 1 day 20 hours 28 minutes 40 seconds

servoy.use.client.timezone: true


We have to change the timezone to ETC/-5 in the smart client and then restart the application server. Once we do that we see the servoy admin settings changes to

Code: Select all

Server Information
Servoy version 4.1.7 -build 690
Repository version 35 (d95ac900-c03d-4f79-95d4-7340001da07e)
Current time: Mon Aug 09 08:36:02 EDT 2010
Uptime: 25 seconds

servoy.use.client.timezone: true


After the change the time-entries all show as intended (we do not clear the java cache or .servoy on the smart client).

I tried clearing the localhost folder inside server/works/catalina and then restarted the App server and then downloaded the smart client and we still have the time entries go off.

Is there a fix for Servoy 4.1.7 or do I have to upgrade to latest version of Servoy 5?

Regards
James Dcunha

[jcompagner]

I tried clearing the localhost folder inside server/works/catalina and then restarted the App server and then downloaded the smart client and we still have the time entries go off.

dont clear that localhost folder!
I have to check the 4.1 branch to see if the latest branch already has some fixes in (that are in the 5.2 release) that the app server changes his time zone to UTC when downloading a client
The client timezone has nothing to do with it. Its the app server that can change its time zone in certain situations.

The workaround for this is start up the app server, clear the java cache on a client, then start there the client once so that it downloads all the jars again from the server.
Then if the server has changed its time zone from EDT to UTC, restart the app server once.

Now when you start a client it shouldnt happen anymore (until you upgrade servoy or some plugins..)

I will check if that fix is also in the 4.1 branch and if it should already be in a release.

[jdcunha]

Thanks Jan !!! Will wait for the new release in Servoy 4.1.x

Regards
James Dcunha

[vincentSchuurhof]

Hi Johan,

Is there any news on this issue? The timezone is being changed quite frequently on our system due to connecting Smart Clients. We are also running a booking system on the same server (Servoy 5.1.4) which is open to the world and this issue is giving us quite some problems.

[jcompagner]

Vincent,

you have to upgrade to 5.2 to get this fix, 5.1.4 was the last for the 5.1.x, its replaced by 5.2

[amcgilly]

I am having a related problem in 5.2.11 build 1022. I have a table with a creation_date column that is set to auto-enter creation server datetime. The solution that inserts into this table is running as a batch process. This is a very active table (called 'packets') in which records are being added constantly (about 90 per minute). The timestamp works, but about once every ten days or so, it stamps a few records in a row with the a timestamp that has reverted to GMT time (insteald of GMT-7, which is what the server is currently set to). Then it goes back to the correct timezone. This has happened about 6 times now.

It only affects this one table, even though there are often insertions being made in other tables at the same time, by the same solution.

The database is Sybase SQL Anywere v11. Here is the other environment info:

Server Information
Servoy version 5.2.11 -build 1022
Port used by RMI Registry: 1099
Repository version 38 (4dd689c6-8de2-4a01-816c-e79ae226a623)
Current time: Fri Jun 08 23:44:19 PDT 2012
Uptime: 6 hours 13 minutes 8 seconds
Server ID: A0DF9CC1-288C-4C33-A7B1-CDD080095B08

User Information
Logged in as: amcgilly

JVM Information
java.vm.name=Java HotSpot(TM) 64-Bit Server VM
java.version=1.6.0_31
java.vm.info=mixed mode
java.vm.vendor=Apple Inc.

Operating System Information
os.name=Mac OS X
os.version=10.6.8
os.arch=x86_64

System Information
Heap memory: allocated=66292K, used=36931K, max=258880K
None Heap memory: allocated=99952K, used=61748K, max=180224K
Dump the current stack/systeminfo

Any suggestions would be appreciated. Thank you.

[Harjo]

We came across, that when we updating a plugin or bean, and after that, the first client downloads the client, the server jumps to GMT-0, when the server is busy repacking all the jars...

So what we now always do, after we released new plugins, libs and beans, is download directly the client, so the server starts repacking the jars.
after repacking the server jumps back to your default GMT (in hour case: GMT+1)

I have discussed this with Johan, en he said, they could'nt change that easily because of how pack2000 (or some other lib) works

[amcgilly]

Thanks Harjo but I think this is a different, though perhaps related, problem. In my case, based on these auto-entered creation dates I'm getting in this one table, the server timestamp is jumping from GMT-7 to GMT-0 for just a couple seconds and then going back to GMT-7 all by itself. And we definitely haven't updated any plugins or beans recently.

[jcompagner]

but that sounds exactly what harjo describes
That something is setting it to GMT-0 for a moment and then back.
That is exactly how Pack200 works when it packs the jars

[amcgilly]

OK. But then something other than updating beans and plugins must be causing this because I have NOT touched the beans or plugins on this server since this started happening.

[Harjo]

http://bugs.sun.com/bugdatabase/view_bu ... id=6791805

[jcompagner]

OK. But then something other than updating beans and plugins must be causing this because I have NOT touched the beans or plugins on this server since this started happening.

But did this happens once or constantly? Do you still see it happening?
Maybe somehow a new client was started that somehow ticked a specific jar to pack it once
I don't know anything else that could cause the quick jump to timezone 0 and back to the normal one on the server.

[amcgilly]

It happened on these dates (Day/Month): 2/4, 17/4, 28/4, 18/5, 11/6.

I know this because we have a batch processor running 24/7 on a separate server that polls the packets table every 5 mins to make sure new packet records are coming into the db at all times. (The plan is to eventually move this server off-site so we have an independent db monitoring capability) Once this timestamp problem started happening I programmed this monitoring process to send me an email alert if it detects a creation date that is set in the future. Each time it sent me an alert I looked in the table and confirmed that there were 3 to 5 records (over a period of about 1 or 2 seconds) that had creation-date timestamps in GMT-0. Records created before and after were correctly set to GMT-7.

The only possible connection to the updating of plugins that I can see is this:

We have a Test environment and a Production environment. Each consists of its own machine, Servoy Server and Sybase SQL Anywhere server.

The packets records which are getting the bad timestamps are being continuously written to the Production DB by a batch process running on the Production server.

The poller I mentioned above which monitors the packets table is currently running on the TEST server but it is polling the production DB. It does NOT write to the production DB, it only queries it, using getDataSetByQuery. See the illustration below.

We HAVE periodically been updating plugins on the TEST server. Do you see any way that could be affecting the production server in this way? I realize it is unorthodox to have two Servoy Servers connecting to the same DB, but as only one of them is writing to the db, and the other is just doing SQL queries I didn't think it would be a problem.

arch.JPG (9.82 KiB) Viewed 7533 times