class_docstr: Represents a tensor of dates.
class_docstr_tok: ["Represents","a","tensor","of","dates","."]
docstr: Initializer.
  
  This initializer is primarily for internal use. More convenient construction
  methods are available via 'dates_from_*' functions.
  
  Args:
    ordinals: Tensor of type int32. Each value is number of days since 1 Jan
      0001. 1 Jan 0001 has `ordinal=1`. `years`, `months` and `days` must
      represent the same dates as `ordinals`.
    years: Tensor of type int32, of same shape as `ordinals`.
    months: Tensor of type int32, of same shape as `ordinals`
    days: Tensor of type int32, of same shape as `ordinals`.
code: def __init__(self, ordinals, years, months, days):
      """Initializer.
  
      This initializer is primarily for internal use. More convenient construction
      methods are available via 'dates_from_*' functions.
  
      Args:
        ordinals: Tensor of type int32. Each value is number of days since 1 Jan
          0001. 1 Jan 0001 has `ordinal=1`. `years`, `months` and `days` must
          represent the same dates as `ordinals`.
        years: Tensor of type int32, of same shape as `ordinals`.
        months: Tensor of type int32, of same shape as `ordinals`
        days: Tensor of type int32, of same shape as `ordinals`.
      """
      # The internal representation of a DateTensor is all four int32 Tensors
      # (ordinals, years, months, days). Why do we need such redundancy?
      #
      # Imagine we kept only ordinals, and consider the following example:
      # User creates a DateTensor, adds a certain number of months, and then
      # calls .day() on resulting DateTensor. The transformations would be as
      # follows: o -> y, m, d -> y', m', d' -> o' -> y', m', d'.
      # The first transformation is required for adding months.
      # The second is actually adding months. Third - for creating a new
      # DateTensor object that is backed by o'. Last - to yield a result from
      # new_date_tensor.day(). The last transformation is clearly unnecessary and
      # it's expensive.
      #
      # With a "redundant" representation we have:
      # o -> y, m, d -> y', m', d' -> o' or o <- y, m, d -> y', m', d' -> o',
      # depending on how the first DateTensor is created. new_date_tensor.day()
      # yields m', which we didn't discard, and if o and o' are never needed,
      # they'll be eliminated (in graph mode).
      #
      # A similar argument shows why (y, m, d) is not an optimal representation
      # either - for e.g. adding days instead of months.
  
      self._ordinals = tf.convert_to_tensor(
          ordinals, dtype=tf.int32, name="dt_ordinals"
      )
      self._years = tf.convert_to_tensor(
          years, dtype=tf.int32, name="dt_years"
      )
      self._months = tf.convert_to_tensor(
          months, dtype=tf.int32, name="dt_months"
      )
      self._days = tf.convert_to_tensor(
          days, dtype=tf.int32, name="dt_days"
      )
      self._day_of_year = None
  
imports: import collections.abc
  import datetime
  import numpy
  import tensorflow.compat.v2
  from tf_quant_finance.datetime import constants
  from tf_quant_finance.datetime import date_utils
  from tf_quant_finance.datetime import periods
  from tf_quant_finance.datetime import tensor_wrapper
label_desc: Use image node_id 1 to create a new DateTensor object from inherited base classes: tensor_wrapper with example: obj = DateTensor(ordinals, years, months, days)