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
