On Sun, Sep 7, 2008 at 7:05 PM, Lester Caine <lester@...> wrote:

> Adam wrote:
>> --- In firebird-support@yahoogroups.com, Lester Caine <lester@...> wrote:
>>> Adam wrote:
>>>
>>>> The clocks on all OSes supported by Firebird use UTC *natively*, and
>>>> only convert to a local representation upon request. In Windows for
>>>> example, GetLocalTime is internally a wrapper around GetSystemTime and
>>>> SystemTimeToTzSpecificLocalTime.
>>> Please can you provide some more proof on this.
>>
>> http://msdn.microsoft.com/en-us/library/ms724493(VS.85).aspx
>>
>> In terms of hardware clock weirdness, I can not explain, but it is
>> getting pretty OT.
>
> Bottom line. It is a fact that in the past we have had major problems with
> maintaining consistent time information in the databases when windows is
> involved. The REALITY of both W2k and XP does not match the link you
> provide,
> and while the GetSystemTime and GetLocalTime functions are available, on
> Windows, the system time CAN be wrong if the hardware clock is not set
> properly, and setting the clock manually EVEN FROM WINDOWS can give the
> wrong
> base time!
>
> In fact I've just checked GetSystemTime and GetLocalTime functions on an XP
> machine, and it is quite possible for GetLocalTime to return 'UTC' while
> GetSystemTime returns an incorrect offset time. Switching on internet update
> of time seems to correct the fault, until you turn the power off, and then
> the
> wrong time is saved to the hardware clock after a reset.
>
> This *IS* on topic since it has been quoted may times before when people
> have
> had problems with consistent UTC times being stored in the database using
> 'NOW'. Windows is simply inconsistent and needs care to ensure that the
> right
> time is maintained, and the only reliable way of doing it *IS* to maintain
> the
> hardware clock on UTC - so that Linux time's are also right - and then
> manage
> windows WITHOUT using the faulty tools provided by M$. And during the hour
> of
> a daylight saving overlap ( 2AM becomes 1AM ) windows applications get
> messed
> up when a file timestamp is prior to a later save. Builder actually screws
> up
> compiles at this point unless you have daylight saving switched off on the
> development machine!
>
> I don't know if this has been fixed in Vista but that introduces another
> level
> of complexity that is pointless for a server machine.
>
> --
> Lester Caine - G8HFL

I have Windows XP
If Windows uses GMT time internally and GetLocalTime is just a wrapper
around GetSystemTime is not to mean that Windows sets the hardware
time to GMT. Hardware time can be set to whatever the system wants as long
as GetSystemTime can get the GMT time out of it. I guess Windows still
keeps compatibility with old MS-DOS (real-mode) applications that can
read hardware time directly, and expect it to be the local time. I guess even
modern Windows applications can read the hardware directly, you just need
to know the addresses the hardware clock can be accessed at.

As I know in standard SQL the TIME/TIMESTAMP/DATETIME data types have
a 'time zone' or 'time zone offset' part (like they have hour, minute and
seconds parts). So when you select and fetch a time stamp you get
'10:30:00.2433 as in GMT+3:00'. I think this would solve every problem if
implemented in Firebird. So whatever pice of time data you would fetch from your
db, you would know in what TZ it was taken.

Thank you,
Timothy Madden