Re: CDR and timestamps

jvemo@cyberspace.com (Jon C Vemo) wrote: :At 03:33 PM 2/25/97 GMT, Juan R. Guzman wrote: ...snip... :}And the issue about daylight saving time is still open. What happens :}when you have two servers in different time zones and one switches to :}daylight savings time and the other doesn't. When server A changes :}it'ss time to one hour back does Serverr B think it's receiving :}transactions from an hour ago when they actually aren't. It doesn't :}matter if you use GMT or not. If you do, the transactions are now GMT-6 :}instead of GMT-5. : :Maybe this is where your 'timestamp and sproc' conflict resultion rules :come into play. However this is an interesting problem. Even if all :timezones do change to DST, they don't all at the same time! No. There is a time syncronization protocol available. I don't remember if it's part of TCP/IP or in Unix, but it does resolve this without problems. All times are converted properly so this problem can't even occur. Every machine operates on their own time, whether it's daylight saving or not, and time received from other machines are allways converted to this local time. For time on the local machine not to go backwards the database will have to convert to GMT (or some other standard time with no daylight saving) and compare timestamps using this time. This is all simple and straightforward using available functionality in every operating system. (It may not be simple to set up and get to work properly, but that's another issue.) If such timestamps are used there is of course a different issue. Even with perfectly syncronized clocks the resolution usually isn't high enough to allways determin what transaction was executed first and last. Also some transactions may take time, and if two transactions on different machines involved the same data there may be extra problems to deal with. One transaction may have started first, while the other finished first or other combinations. These situations will probably have to use some conflict resolution methods. These I don't know anything about, so I can't comment further. However do remember we are talking about a fairly special type of data replication here, and it is *not* appropriate for all purposes. Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org