Re: Importing issue within AddressManager

Hi Riccardo,

Thank you again for all the work done.

I confirm the issue is now fixed building the Framework Addresses from 
svn revision 4113.

I was able to import successfully all my family birthdays with my 
TimeZone Europe/Paris and Lang set to "fr_FR.UTF-8". I closed and 
opened again the AddressManager: all was safely saved as expected.

I confirm also the appropriate VCF format 3.0 (cf. John Doe vcard in 
the previous attached examples).
So we have now a solid AddressManager to complete GNUMail and 
SimpleAgenda, which contribute to provide together a good desktop 
experience.

On 2025-11-24 23:19:46 +0100 Riccardo Mottola 
<[email protected]> wrote:

> 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
> 

-- 
Patrick Cardona - Pi400 - GNU/Linux aarch64 (Debian 13.2)
Xorg (1:7.7+24) - libcairo2 (1.18.4-1+rpt1 arm64)
Window Maker (0.96.0-4) - GWorkspace (1.1.0 - 02 2025) - Theme: 
AGNOSTEP - MUA: GNUMail (1.4.0)