Hi Robert, Hi Riccardo, On 2025-11-19 02:19:29 +0100 Robert Slover <[email protected]> wrote:
> I’ve been following this thread a bit. > One thing I’d note is that there could be a difference based on time zone > if the date is being parsed as a timestamp in the local time zone. > > I believe I saw Patrick’s time zone as Central European (UTC +1:00) earlier > in the thread. I didn’t mention this earlier because I assumed Riccardo was > in the same time zone (Italy is also Central European Time Zone IIRC). But, > it is always possible that Riccardo is using an alternative TZ on his > computers such as GMT or UTC? I do this with all of my servers. Only my > personal laptop is set to the local time zone. > > Anyway, if you parse a date into a Unix timestamp in the local time zone, > assume the time portion to be “all zeros”, and are east of UTC +0:00, the > “day” component when stored as offset from January 1, 1970, will be the > previous day. > For example, today is my lovely wife’s birthday (November 18). If your > local time zone is ahead of UTC (e.g., UTC+08:00) and you try to parse her > birth date in local time zone and assume 00:00:00 as local time, this is > actually a time on the previous UTC day. The time 2025-11-18 00:00:00 in a > UTC+08:00 time zone is 2025-11-17 16:00:00 in UTC. > > For something like a birth date, I think the parsing and the formatting > should always be done with respect to UTC +0:00 time zone to prevent these > bogus “date shifts”. I’m nowhere near a computer (responding from my > phone) to look at either GNUstep or the AddressManager source code, but I > think it would be worth it to spend a little time exploring whether this is a > possible issue. > HTH > > —Robert Firstly, thank you to point this hypothesis. I confirm my TZ is 'Europe/Paris'. My tests were as following: 1) Changing the TZ to America/NY and setting LANG to "en_EN.UTF-8"... Importing vcard of John Doe seemed bad while shown in AddressView, again BDAY was 25... Closing AddressManager. To avoid a side-effect, I logged out and logged in again. 2) Same context: America/NY and en_EN.UTF-8 But this time, the BDAY of John Doe was as expecetd: 26 in AdressView. I did not import the vcard again, it was the previous import. So we can guess the TimeZone has an effect while the database is saved. 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. >> On Nov 18, 2025, at 17:47, Riccardo Mottola <[email protected]> >> wrote: >> Hi Patrick > (...) > >> I updated my other workstation running FreeBSD and latest gnustep and >> AddressManager and tried there. It works. >> Attached the screenshot of exactly the same VCF I posted to the mailing >> list. I guess FreeBSD and Linux do the same on dates. > >> So I think it can be: >> - a real issue on your side. In that case I can only think on your >> locale. Would you mint trying to set e.g LANG=C.UTF-8 as a test? With TZ 'Europe/Paris' and LANG=C.UTF-8, the imported date was immediately false, even in AddressView: 07/25/1965 and saved as is in the database then while opening again Addressmanager. >> - an issue on your build side, Maybe you have two versions installed >> (System vs. Local) or some other "dirtiness" My apps are installed by scripts the same way and in the case of Addresses, it only fetch sources from Savannah subversion. So only one and up to date version. > >> Or well, something I cannot think of, including a issue with base. The hypothesis of Robert seems worth to go into depth. And maybe not only for Addresses. Cheers, Patrick -- Patrick Cardona - Pi400 - GNU/Linux aarch64 (Debian 13.1) Xorg (1:7.7+24) - libcairo2 (1.18.4-1+rpt1 arm64) Window Maker (0.96.0) - GWorkspace (1.1.0 - 02 2025) - Theme: AGNOSTEP - MUA: GNUMail (1.4.0)
