| Subject | Re: [firebird-support] Re: current_time result differs from the time on the server. |
|---|---|
| Author | Mitchell Peek |
| Post date | 2007-04-10T01:56:58Z |
Adam wrote:
It would depend on how it was installed, but I believe it relates to
the session. By default I think it is installed under the LOCALSYSTEM
user, so that is the context the CURRENT_TIME would be evaluated as.
If the server was set to the incorrect UTC time, or the adjustment was
incorrect (say the recent US DST patch wasn't installed correctly), it
would be possible that the service would display the incorrect local time.
If the server UTC time was correct but the DST patch was not applied
on the server but was on the client, the client timezone redirection
would mean the clock would display the right time to the client.
Out of curiousity, if you have clients in multiple timezones, what are
you using CURRENT_TIME for? I would have thought you would need to
work in UTC and adjust at the client.
--------------------------
To answer your last question first. I do not have clients in mulitple
time zones. I do have developers in multiple time zones, however,
therefore, my statement about the remote desktop session from another
time zone.
Your previous two paragraphs have me somewhat confused (not hard to do
sometimes).
What I observed was this...
I noticed some times that didn't look correct stored in the database
(records with a time stamp that were ~ 1 hour ahead of the current time)
I then did 3 things.
1) I ran a query asking for Current_time against the DB from my local
machine. the time was exactly one hour ahead of the time on my machine.
2) I established a remote desktop session into the database server and
ran the same query directly from the DB server itself. It also showed
the time 1 hour ahead of the correct time. Furthermore, it differed
from the time shown in the remote desktop sessions desktop, again,
exactly 1 hour ahead.
3) I closed all apps connected to the server, restarted the FB service
and repeated 1 and 2. in both cases, the correct time was returned.
So far, no new instances of this, so, perhaps i can just forget it.
Unless this sparks more thoughts....
Again, thanks so much for taking the time to respond to this.
regards,
Mitch
It would depend on how it was installed, but I believe it relates to
the session. By default I think it is installed under the LOCALSYSTEM
user, so that is the context the CURRENT_TIME would be evaluated as.
If the server was set to the incorrect UTC time, or the adjustment was
incorrect (say the recent US DST patch wasn't installed correctly), it
would be possible that the service would display the incorrect local time.
If the server UTC time was correct but the DST patch was not applied
on the server but was on the client, the client timezone redirection
would mean the clock would display the right time to the client.
Out of curiousity, if you have clients in multiple timezones, what are
you using CURRENT_TIME for? I would have thought you would need to
work in UTC and adjust at the client.
--------------------------
To answer your last question first. I do not have clients in mulitple
time zones. I do have developers in multiple time zones, however,
therefore, my statement about the remote desktop session from another
time zone.
Your previous two paragraphs have me somewhat confused (not hard to do
sometimes).
What I observed was this...
I noticed some times that didn't look correct stored in the database
(records with a time stamp that were ~ 1 hour ahead of the current time)
I then did 3 things.
1) I ran a query asking for Current_time against the DB from my local
machine. the time was exactly one hour ahead of the time on my machine.
2) I established a remote desktop session into the database server and
ran the same query directly from the DB server itself. It also showed
the time 1 hour ahead of the correct time. Furthermore, it differed
from the time shown in the remote desktop sessions desktop, again,
exactly 1 hour ahead.
3) I closed all apps connected to the server, restarted the FB service
and repeated 1 and 2. in both cases, the correct time was returned.
So far, no new instances of this, so, perhaps i can just forget it.
Unless this sparks more thoughts....
Again, thanks so much for taking the time to respond to this.
regards,
Mitch