The purpose of this feature request is to support date-only birthday values, which are pretty common. EDS supports only date-only values.

The boolean flag is needed, but it is not enough. Because the current GDateTime value is defined as "birthday in UTC", the EDS backend does a "date + 00:00 local time -> UTC" conversion. To retrieve the original data, one has to convert back to local time.

To do that reliably, the local time zone used by folks must be part of the BirthdayDetails value. Otherwise the following problem can occur:
* folks uses local time zone A to generate the value,
* the user (or device) switches to a different local time zone,
=> the app does the transformation incorrectly.

Can we make it so that the type of the "birthday" property is a type derived from GDateTime with the extra information included? That would make reading and interpreting the value easier and consistent (self-contained, no context needed).

Or we could just add a second property to BirthdayDetails: GDate birthday_date. This would be in addition to birthday. It would be non-null when birthday is non-null; but could also be non-null when the person’s birth date, but not time, is known (i.e. the EDS case). In this case, birthday would be null.

That means we don’t end up inventing our own date struct, and can also implement this without breaking API.

From discussion on the mailing list, users would also like to be able to store a date only (i.e. not a year of birth as well), giving the following three cases:
 • Full year, date and time of birth stored (year, month, day, time)
 • Year and date of birth stored (year, month, day)
 • Date of birth (known as ‘birthday’ in some languages) only (month, day)

Perhaps we should go for adding a couple of flags and keeping the DateTime then. e.g.
{
    public abstract DateTime? birthday { get; set; }
    public abstract TimeZone? timezone { get; set; }  /* null if time is invalid */
    public abstract bool year_is_valid { get; set; }
}

Although as Patrick says, it might be best if this was a self-contained struct in a single property.

Also, we should carefully define the terminology we use in the BirthdayDetails documentation, since the word ‘birthday’ can be translated differently into different locales — in some it can mean (year, month, day) whereas in others it can mean (month, day).

Hey Philip, I'm thinking of adding this to the next version of Contacts.
How interested would you be in adding this in the next folks release?

(On a side note: I agree that your approach in comment 3 is probably the best wat to go).

(Although, now I think about it: doesn't the DateTime already contain a TimeZone internally? Do we still need to explicitly store it then?)

(In reply to Niels De Graef from comment #6)
> (Although, now I think about it: doesn't the DateTime already contain a
> TimeZone internally? Do we still need to explicitly store it then?)

Indeed, I’m not sure why that was not considered before. The additional timezone should not be needed, so we’d need a boolean for whether to use the time instead. i.e.

{
    public abstract DateTime? birthday { get; set; }
    public abstract bool time_is_valid { get; set; }
    public abstract bool year_is_valid { get; set; }
}

Niels, I don’t have time to implement this at the moment. Do you want to have a go? I can review patches and discuss things if needed.

I took some small steps into implementing this, but it seems I'm stuck on something major: I believe EDS doesn't support birthdays without a year (or at least neither Evolution nor E.ContactData seem to indicate any support for this).

If we can't do this for Edsf.Persona, then that would be a bit of a shame as this would mean we can't support this properly for the most common use case of folks (and gnome-contacts).

Anyone here with a bit more knowledge on EDS that can give me some pointer if this might be possible still?

(In reply to Niels De Graef from comment #8)
> Anyone here with a bit more knowledge on EDS that can give me some pointer
> if this might be possible still?

As far as I remember (and this is from a while ago), EDS does *not* support birthdays without a year.

You could add support for it in EDS, or hard-code a particular year (the year 0, for example) which indicates that the year is unset. EDS would be unaware of what the year means, which means it would show the contact’s birthday with their age as something ridiculous; but folks could handle it.

I would vote for adding support for it in EDS/Evolution.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/44.