[OGo-Users] Time issues with OGo

[Samuli Seppänen]

> On Apr 16, 2007, at 09:16, Samuli Seppänen wrote:
>> 1) Should I keep Postgresql database in GMT?
> 
> Not sure what you mean by that.

Postgresql seems to have a setting for client timezone. I'm not sure how
this affects OGo, if at all:

/etc/postgresql/7.4/postgresql:

#---------------------------------------------------------------------------
# CLIENT CONNECTION DEFAULTS
#---------------------------------------------------------------------------

# - Locale and Formatting -

#timezone = unknown             # actually, defaults to TZ environment

I was hoping somebody had an idea of that. But OGo is a client, so I
guess it's possible that this affects OGo. Then again, if OGo stores
timezone info along with events in the database, it shouldn't matter.

>> 2) Does OGo add it's own DST on top of (Linux) system's own DST? So if
>> automatic DST is activated in both Linux _and_ OGo, will the OGo clock
>> be off 1 hour half of the year?
> 
> Both, OGo and Linux use UTC internally. How Linux adjusts your hardware
> clock doesn't affect any programs.
>
> But yes, OGo (more exactly libFoundation) has own timezone processing
> code. Since Linux works in UTC, it will never get applied twice.
>

Ok, so OGo does not use local time (UTF + GMT offset [+ DST]) as the
basis of it's time calculations, but Linux system clock, which is in
UTC. At least according to time howto Linux should never modify the
hardware clock (Real-time clock a.k.a. CMOS clock), unless explicitly
told to (with hwclock, for example).

>> 3) Is the only safe setting for TimeZoneName still "GMT"? Can it be
>> changed to "GMT" on a running system without messing everything up?
> 
> Its the only setting which is tested and recommended. It *should* only
> affect logging output, but who knows.
> 
> You can change it to something else, but I'm not sure whether this would
> move the dates. Could be. (try it on a test system).

I'll test it on a cold system first - for historic reasons some of our
OGo systems have TimeZoneName been mistakenly changed to GMT+2, EET or
something else.

> 
>> 4) Is the problem shown below happening due to hypothesis I wrote in
>> question 2 or something else entirely:
>>
>> So, when I try to synchronize events between Nokia and OGo by using
>> Funambol + GroupDAV plugin event begin and endtimes are consistently 1
>> hour off, either less or more than they ought to be:
>>
>> An event created in Nokia:
>>
>> Nokia Timezone: GMT+2 (does automatic DST)
>> Real begintime: 8.00
>> Real endtime: 8.05
>> Vcard begintime: 5.00 (-3 hours)
>> Vcard endtime: 5.05 (-3 hours)
>> OGo begintime: 9.00 (+4 hours)
>> OGo endtime: 9.05 (+4 hours)
>>
>> This looks good, except for the OGo part. Now onto the OGo event:
>>
>> OGo TimeZone: EET (GMT+2 with DST)
>> Real begintime: 7.00
>> Real endtime: 8.00
>> Vcard begintime: 3.00 (-4 hours)
>> Vcard endtime: 4.00 (-4 hours)
>> Nokia begintime: 6.00 (+3 hours)
>> Nokia endtime: 7.00 (+3 hours)
>>
>> Now for some reason OGo adds or decreases 4 hours from begin- and
>> endtimes, instead of 3 as it should. Nokia on the other hand (correctly)
>> adds or decreases three hours to the vCard as it is now GMT+2 + DST (1
>> hour). All this seems like if OGo was adding it's 1 hour on top of the
>> Linux system's time, even though the system has already switched to DST
>> (GMT+3).
> 
> As mentioned it can't be 2). It could be various things, at least three
> timezone implementations are part of the process (Nokia, then Java, then
> libFoundation).
> You should file a bug report including all the necessary information (eg
> dumps of the vCard which is exchanged).
> 
> BTW: vCards have no begintime. You probably refer to iCalendar.

Yes, my mistake. I meant iCal. I'll try these tests on a clean system -
current tests have been done _mostly_ on systems which have some history
behind them. It could be Funambol messing something up, unless it's OGo
due to some weird settings. If the problem persists, I'll file a bugreport.

Samuli