Subject | Re: timestamp trigger? |
---|---|
Author | Adam |
Post date | 2006-10-16T23:08:17Z |
Lester wrote:
You have to run the server at UTC time as it's the only way currently
to match 'NOW' on other databases ;)
---
Using a timestamp as an ordering mechanism is a bad idea, even when
you are using UTC. It is not uncommon for server clocks to wander a
fair bit, especially if both the power supply and any attached UPS is
not excellent. It is unfortunately not uncommon for a server to lose
or gain a few seconds a day. Pretty much every Windows server out
there will synch with an NTP server at a calculated frequency (based
on how far out it was at last synchronisation - usually around 7 - 10
days for standalone or every hour for machines where the NTP server is
on the local domain).
The point is that, regardless of how little the clock wanders, if it
does wander forwards, at some stage either an NTP service or a human
will set it back. In the process, a record may come through with a
earlier time than the record that chronologically followed it.
---
Lester wrote:
We DO need a UTC_NOW so that times are in chronological even
if the clients are in different time zones :)
---
I totally agree with the need for UTC_NOW. I know it is a request in
the tracker (because I made it). However for the above reasons I still
would not use it to order the times.
Adam
You have to run the server at UTC time as it's the only way currently
to match 'NOW' on other databases ;)
---
Using a timestamp as an ordering mechanism is a bad idea, even when
you are using UTC. It is not uncommon for server clocks to wander a
fair bit, especially if both the power supply and any attached UPS is
not excellent. It is unfortunately not uncommon for a server to lose
or gain a few seconds a day. Pretty much every Windows server out
there will synch with an NTP server at a calculated frequency (based
on how far out it was at last synchronisation - usually around 7 - 10
days for standalone or every hour for machines where the NTP server is
on the local domain).
The point is that, regardless of how little the clock wanders, if it
does wander forwards, at some stage either an NTP service or a human
will set it back. In the process, a record may come through with a
earlier time than the record that chronologically followed it.
---
Lester wrote:
We DO need a UTC_NOW so that times are in chronological even
if the clients are in different time zones :)
---
I totally agree with the need for UTC_NOW. I know it is a request in
the tracker (because I made it). However for the above reasons I still
would not use it to order the times.
Adam