Lester Caine wrote:

> Jiri Cincura wrote:
>
>> = m. Th = wrote:
>>
>>> - If you talking about "now" as a variable which gets the current time,
>>> this isn't a problem in a LAN, at least in a Windows Domain one, dunno
>>> for Linux, but the things should be the same, where it's imposed (by the
>>> Kerberos protocol which is used) that all the workstations to have the
>>> clocks in sync. (ie. a time server is required).
>>>
>> Sorry, if I miss something and I ask dumb question, but how will be solved,
>> if one machine is in England (GMT) and other in Ohio (GMT-5 AFAIK)? And what
>> happends if one or other will crash, what about the syncing?
>>
>
> This is the precise reason that 'NOW' is actually wrong. Other databases
> always use a UTC/GMT 'NOW' and require you to use LOCAL_... if you
> really want a local time. I'm having to manually insert UTC timestamps
> where this is trying to provide cross database support :(
> Not just a clustering problem - a major headache generally.
>
> While I understand the discussion on time sync, if time is an important
> part of the update process, then as has been stated NTP is not good
> enough. I'm still using Rugby time code receivers and we still have
> problems with the second not changing identically across a site ( we get
> some picky SOB's who stand at one end of a platform and expect to see
> all the clocks change at once ) but fortunately that is within the spec
> - as long as the clock display is within a one second window... I can
> see a situation with multiple sites around the world tracking
> astronomical events needing accurate time and in these special cases
> atomic clocks would be the only solution, but I think that where a
> duplicate data record *IS* a copy of another, the timestamp should be
> part of the insert/update data not added separately by the server? Again
> not limited to clustering, but a general requirement for good design
> when multiple copies are required?
>
>

Note that row based replication doesn't suffer from this type of
problem. Whatever is stored on the original insert is propagated.

The Firebird date type (klunks since November 17, 1858) is based on the
VAX date datatype. Each was based on local on local time to avoid
problems with equality retrievals when only date was stored in a
combined date/time type. The SQL standard addressed the problem by
separate date, time, and timestamp types.

It would be nice to claim that DSRI, Rdb, and Interbase preceded the
Internet (more or less true), but the issue of UTC versus local time was
already biting us on the ARPAnet when there still about 50 nodes. I was
responsible for the internal VMS datatype, but I'm afraid I'm the one
that pushed to make it an official datatype. So, it's all my fault.