IMPORTANT NOTES: - Requesting person.birthday requires membership in the purpose limited data ACL group sgbe-ac-d-birthday-(read|mutate). Contact people-api-eng@ for assistance with initial setup. - The birthday field should not be used to calculate the requester's age! To determine the requester's age, use person.age_range_repeated. - For more details about age see go/peopleapi-howto/age Birthday value may not be present: - Consumer users generally required to have account birthday set (required at account creation), though some users created via legacy flows may not have birthday present. - Dasher users generally don't require birthday, but could optionally have it set by users. - Any other types of accounts (e.g. robot, service) do not have birthdays. - Account Birthday field may be present but without birthday value set for grace period birthday (provisional new birthday). For users that do have birthday data: - "Profile Birthday" (person.birthday.metadata.container is PROFILE) may not have a year set if user "hides" the year. - "Account Birthday" (see api-specific notes below) will only be returned for the requester's own profile. - People API (go/peopleapi): Account birthday is only supported in GetPeople for PeopleAPI. If account birthday is needed, use a request mask with: include_field { paths: "person.birthday" } include_container: ACCOUNT - People API++ (go/peopleapi++): Account birthday is supported for most apis in PeopleAPI++. If account birthday is needed, use a request mask with: include_field { paths: "person.account_birthday" } include_container: PROFILE (note: it will also need include_container: DOMAIN_PROFILE because they must be requested together: go/people-api-masks#profile-domain_profile) - See go/papi-vs-papi++#birthday for more details.

Attributes

• ageDisableGracePeriod (type: GoogleApi.ContentWarehouse.V1.Model.AppsPeopleOzExternalMergedpeopleapiBirthdayAgeDisableGracePeriod.t, default: nil) - Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.
• birthdayDecoration (type: GoogleApi.ContentWarehouse.V1.Model.SocialGraphApiProtoBirthdayDecoration.t, default: nil) - Whether the user has opted in to display their birthday via photo decorations. Only supported for PROFILE/DOMAIN_PROFILE container.
• birthdayResolution (type: String.t, default: nil) - Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.
• calendarDay (type: GoogleApi.ContentWarehouse.V1.Model.GoogleTypeDate.t, default: nil) - 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.
• dateMs (type: String.t, default: nil) - 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.
• dateMsAsNumber (type: String.t, default: nil) - 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.
• metadata (type: GoogleApi.ContentWarehouse.V1.Model.AppsPeopleOzExternalMergedpeopleapiPersonFieldMetadata.t, default: nil) -
• prompt (type: GoogleApi.ContentWarehouse.V1.Model.SocialGraphApiProtoPrompt.t, default: nil) - People Prompts settings for contact birthday data. Only supported for CONTACT container.
• value (type: String.t, default: nil) - Actual value entered. Allows unstructured values.