AppsPeopleOzExternalMergedpeopleapiBirthday

Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.

Whether the user has opted in to display their birthday via photo decorations. Only supported for PROFILE/DOMAIN_PROFILE container.

Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.

Birthdays are more accurately represented as a calendar day that does not depend on a timestamp representation at all. When given a timestamp, there are lots of opportunities to make mistakes, so a CalendarDay proto is replacing timestamps. Currently this is always returned by PeopleApi on reads that include birthday fields. New clients should write using calendar_day. Clients that were already writing via date_ms are allowlisted such that writes use that field. Old callers should migrate to writing BOTH date_ms and calendar_day values. If those are consistent, they may be removed from the 'legacy_timestamp_event_write_behavior_enabled' capability.

Birthdays are currently represented as timestamp values, although the interpretation of these timestamp values is a calendar date. Clients are recommended to read the calendar_day field, which is easier to work with than date_ms. New clients writing to PeopleApi must set calendar_day instead of date_ms. There are a few important details about how this value should be mapped to a calendar date that should be consistent among all clients. 1. Epoch - The epoch or calendar date equivalent to 0 ms is chosen to be 1970-01-01 UTC. 2. Timezone - All of the conversions to calendars should occur in the UTC timezone. We don't typically think of someones birthday changing when they travel, so clients should not use local times. 3. Calendar - The calendar used for the dates should be a Gregorian proleptic calendar. Proleptic means that the rules of the Gregorian calendar are retrofitted to before its adoption. It is easy to get this wrong, particularly with the java GregorianCalendar class, which by default is a mixed Gregorian/Julian calendar. Joda Time makes this easy, but if it's not an option, look into GregorianCalendar.setGregorianChange(). 4. Omitted years - Clients have chosen to represent birthdays or events without years as timestamps within the year zero. When the computed date has a year of 0, it means the client did not specify a year. Note that a year 0 does not exist in a chronology like the familiar Anno Domini (A.D. and B.C.); clients must agree on year numbering. 5. Year Numbering - The chronology used to map dates to the calendar should use Astronomical Year Numbering so that the year 0 is defined and dates before it have a negative year. If libraries only provide Anno Domini, then the year of 1 BC corresponds to year zero and an omitted user provided year. Other BC values are presumed rare, but clients should still not ignore the era and interpret the year as an A.D. value, especially if writing values back to PeopleApi.

date_ms_as_number contains the same data as date_ms, but has a different type in generated javascript bindings. Non javascript clients can ignore it.

People Prompts settings for contact birthday data. Only supported for CONTACT container.

Actual value entered. Allows unstructured values.