/*
 * Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 * in compliance with the License. You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software distributed under the License
 * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
 * or implied. See the License for the specific language governing permissions and limitations under
 * the License.
 */
/*
 * This code was generated by https://github.com/googleapis/google-api-java-client-services/
 * Modify at your own risk.
 */

package com.google.api.services.contentwarehouse.v1.model;

/**
 * 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.
 *
 * <p> This is the Java data model class that specifies how to parse/serialize into the JSON that is
 * transmitted over HTTP when working with the Document AI Warehouse API. For a detailed explanation
 * see:
 * <a href="https://developers.google.com/api-client-library/java/google-http-java-client/json">https://developers.google.com/api-client-library/java/google-http-java-client/json</a>
 * </p>
 *
 * @author Google, Inc.
 */
@SuppressWarnings("javadoc")
public final class AppsPeopleOzExternalMergedpeopleapiBirthday extends com.google.api.client.json.GenericJson {

  /**
   * Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private AppsPeopleOzExternalMergedpeopleapiBirthdayAgeDisableGracePeriod ageDisableGracePeriod;

  /**
   * Whether the user has opted in to display their birthday via photo decorations. Only supported
   * for PROFILE/DOMAIN_PROFILE container.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private SocialGraphApiProtoBirthdayDecoration birthdayDecoration;

  /**
   * Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private java.lang.String birthdayResolution;

  /**
   * 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.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private GoogleTypeDate calendarDay;

  /**
   * 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.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key @com.google.api.client.json.JsonString
  private java.lang.Long dateMs;

  /**
   * 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.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key @com.google.api.client.json.JsonString
  private java.lang.Long dateMsAsNumber;

  /**
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private AppsPeopleOzExternalMergedpeopleapiPersonFieldMetadata metadata;

  /**
   * People Prompts settings for contact birthday data. Only supported for CONTACT container.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private SocialGraphApiProtoPrompt prompt;

  /**
   * Actual value entered. Allows unstructured values.
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private java.lang.String value;

  /**
   * Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.
   * @return value or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthdayAgeDisableGracePeriod getAgeDisableGracePeriod() {
    return ageDisableGracePeriod;
  }

  /**
   * Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.
   * @param ageDisableGracePeriod ageDisableGracePeriod or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthday setAgeDisableGracePeriod(AppsPeopleOzExternalMergedpeopleapiBirthdayAgeDisableGracePeriod ageDisableGracePeriod) {
    this.ageDisableGracePeriod = ageDisableGracePeriod;
    return this;
  }

  /**
   * Whether the user has opted in to display their birthday via photo decorations. Only supported
   * for PROFILE/DOMAIN_PROFILE container.
   * @return value or {@code null} for none
   */
  public SocialGraphApiProtoBirthdayDecoration getBirthdayDecoration() {
    return birthdayDecoration;
  }

  /**
   * Whether the user has opted in to display their birthday via photo decorations. Only supported
   * for PROFILE/DOMAIN_PROFILE container.
   * @param birthdayDecoration birthdayDecoration or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthday setBirthdayDecoration(SocialGraphApiProtoBirthdayDecoration birthdayDecoration) {
    this.birthdayDecoration = birthdayDecoration;
    return this;
  }

  /**
   * Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.
   * @return value or {@code null} for none
   */
  public java.lang.String getBirthdayResolution() {
    return birthdayResolution;
  }

  /**
   * Only supported for PROFILE/DOMAIN_PROFILE/ACCOUNT container.
   * @param birthdayResolution birthdayResolution or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthday setBirthdayResolution(java.lang.String birthdayResolution) {
    this.birthdayResolution = birthdayResolution;
    return this;
  }

  /**
   * 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.
   * @return value or {@code null} for none
   */
  public GoogleTypeDate getCalendarDay() {
    return calendarDay;
  }

  /**
   * 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.
   * @param calendarDay calendarDay or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthday setCalendarDay(GoogleTypeDate calendarDay) {
    this.calendarDay = calendarDay;
    return this;
  }

  /**
   * 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.
   * @return value or {@code null} for none
   */
  public java.lang.Long getDateMs() {
    return dateMs;
  }

  /**
   * 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.
   * @param dateMs dateMs or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthday setDateMs(java.lang.Long dateMs) {
    this.dateMs = dateMs;
    return this;
  }

  /**
   * 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.
   * @return value or {@code null} for none
   */
  public java.lang.Long getDateMsAsNumber() {
    return dateMsAsNumber;
  }

  /**
   * 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.
   * @param dateMsAsNumber dateMsAsNumber or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthday setDateMsAsNumber(java.lang.Long dateMsAsNumber) {
    this.dateMsAsNumber = dateMsAsNumber;
    return this;
  }

  /**
   * @return value or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiPersonFieldMetadata getMetadata() {
    return metadata;
  }

  /**
   * @param metadata metadata or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthday setMetadata(AppsPeopleOzExternalMergedpeopleapiPersonFieldMetadata metadata) {
    this.metadata = metadata;
    return this;
  }

  /**
   * People Prompts settings for contact birthday data. Only supported for CONTACT container.
   * @return value or {@code null} for none
   */
  public SocialGraphApiProtoPrompt getPrompt() {
    return prompt;
  }

  /**
   * People Prompts settings for contact birthday data. Only supported for CONTACT container.
   * @param prompt prompt or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthday setPrompt(SocialGraphApiProtoPrompt prompt) {
    this.prompt = prompt;
    return this;
  }

  /**
   * Actual value entered. Allows unstructured values.
   * @return value or {@code null} for none
   */
  public java.lang.String getValue() {
    return value;
  }

  /**
   * Actual value entered. Allows unstructured values.
   * @param value value or {@code null} for none
   */
  public AppsPeopleOzExternalMergedpeopleapiBirthday setValue(java.lang.String value) {
    this.value = value;
    return this;
  }

  @Override
  public AppsPeopleOzExternalMergedpeopleapiBirthday set(String fieldName, Object value) {
    return (AppsPeopleOzExternalMergedpeopleapiBirthday) super.set(fieldName, value);
  }

  @Override
  public AppsPeopleOzExternalMergedpeopleapiBirthday clone() {
    return (AppsPeopleOzExternalMergedpeopleapiBirthday) super.clone();
  }

}
