Re: Importing issue within AddressManager

Riccardo Mottola <[email protected]>
Newsgroups gmane.comp.lib.gnustep.general
Message-ID <[email protected]>
Hi Robert & Patrick,

the code looked fine, I read Robert's answer, did think about it (got 
bitten by it in the past too...) but the code looked safe. Well. I 
needed a deeper look.

Patrick Cardona wrote:
> 3) Reverting to TZ 'Europe/Paris', same LANG en_EN.UTF-8: the BDAY is still as expected (26).
>
> Now with LANG 'fr_FR.UTF-8', the BDAY is still as expected (26).
>
> We can guess LANG has not a bad effect after the date has been stored in the database.
>
> 4) With TZ 'Europe/Paris':
>
> Deleting Person John Doe.
> Importing again: date is as expected in AdressViev: 26.
> Closing app. A Panel ask to save. Save and Quit.
> Opening AddressManager again: the BDAY is bad: 25.
>
> This 4th test confirm the TZ context was influent on the way the date was saved in the database.

I had a deep check on the code and discovered a weak spot.

The code uses NSCalendarDate internally, which is actually a "time 
instant" to store the Birth Day.
Load and Save of the DB is handled as Plist and is supposed to be safe 
(and apparently is).

However, dates coming from a VCF were set to midnight, dates entered in 
the UI were set at midday.

All internal Data is stored in UTC

So, for safety, I added a conversion step where I create explicitely an 
UTC date at midday, once I read it from presumably Local Time zone ad 
midnight.

Why it used to work for me is a small mystery, but that would take us 
astride.

Richard was able to reproduce your issue and confirmed that after my 
latest fix it went away.

Please retest once again, with your correct time zone and let me know!

Riccardo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.