Currently, there is only one class-wide option for Zend_Date. Several methods use date format strings, in a way similar to PHP's date(). If you are more comfortable with PHP's date format specifier than with ISO format specifiers, then you can use Zend_Date::setOptions('format' => 'php'). Afterward, use PHP's date format specifiers for all functions which accept a $format parameter. Use Zend_Date::setOptions('format' => 'iso') to switch back to the default mode of supporting only ISO date format tokens. For a list of supported format codes, see Section 8.5.4, “Self-defined OUTPUT formats using PHP's date() format specifiers”

Once input has been normalized via the creation of a Zend_Date object, it will have an associated timezone, but an internal representation using standard UNIX timestamps . In order for a date to be rendered in a localized manner, a timezone must be known first. The default timezone is always GMT/UTC. To examine an object's timezone use getTimeZone()). To change an object's timezone, use setTimeZone()). All manipulations of these objects are assumed to be relative to this timezone.

Beware of mixing and matching operations with date parts between date objects for different timezones, which generally produce undesireable results, unless the manipulations are only related to the timestamp. Operating on Zend_Date objects having different timezones generally works, except as just noted, since dates are normalized to UNIX timestamps on instantiation of Zend_Date.

Most methods expect a constant selecting the desired $part of a date, such as Zend_Date::HOUR. These constants are valid for all of the functions below. A list of all available constants is provided in Section 8.5.2, “List of All Constants” . If no $part is specified, then Zend_Date::TIMESTAMP is assumed. Alternatively, a user-specified format may be used for $part, using the same underlying mechanism and format codes as Zend_Locale_Format::getDate() . If a date object is constructed using an obviously invalid date (e.g. a month number greater than 12), then Zend_Date will throw an exception, unless no specific date format has been selected -i.e. $part is either null or Zend_Date::DATES (a "loose" format).

<?php
$date1 = new Zend_Date('Feb 31, 2007', null, 'en_US');
echo $date1, "\n"; // outputs "Mar 3, 2007 12:00:00 AM"

$date2 = new Zend_Date('Feb 31, 2007', Zend_Date::DATES, 'en_US');
echo $date2, "\n"; // outputs "Mar 3, 2007 12:00:00 AM"

$date3 = new Zend_Date('Feb 31, 2007', 'MM.dd.YYYY'); // strictly restricts interpretation to specified format
echo $date3, "\n"; // outputs "Mar 3, 2007 12:00:00 AM"
?>

If the optional $locale parameter is provided, then the $locale disambiguates the $date operand by replacing month and weekday names for string $date operands, and even parsing date strings expressed according to the conventions of that locale (see Zend_Locale_Format::getDate() ). The automatic normalization of localized $date operands of a string type occurs when $part is one of the Zend_Date::DATE* or Zend_Date::TIME* constants. The locale identifies which language should be used to parse month names and weekday names, if the $date is a string containing a date. If there is no $date input parameter, then the $locale parameter specifies the locale to use for localizing output (e.g. the date format for a string representation). Note that the $date input parameter might actually have a type name instead (e.g. $hour for addHour()), although that does not prevent the use of Zend_Date objects as arguments for that parameter. If no $locale was specified, then the locale of the current object is used to interpret $date, or select the localized format for output.

The methods add(), sub(), compare(), get(), and set() operate generically on dates. In each case, the operation is performed on the date held in the instance object. The $date operand is required for all of these methods, except get(), and may be a Zend_Date instance object, a numeric string, or an integer. These methods assume $date is a timestamp, if it is not an object. However, the $part operand controls which logical part of the two dates are operated on, allowing operations on parts of the object's date, such as year or minute, even when $date contains a long form date string, such as, "December 31, 2007 23:59:59". The result of the operation changes the date in the object, except for compare(), and get().

<?php
require_once 'Zend/Date.php';

$date = new Zend_Date(); // $date's timestamp === time()

// changes $date by adding 12 hours
$date->add('12', Zend_Date::HOUR);
print $date;
?>

Convenience methods exist for each combination of the basic operations and several common date parts as shown in the tables below. These convenience methods help us lazy programmers avoid having to type out the date part constants when using the general methods above. Conveniently, they are named by combining a prefix (name of a basic operation) with a suffix (type of date part), such as addYear(). In the list below, all combinations of "Date Parts" and "Basic Operations" exist. For example, the operation "add" exists for each of these date parts, including addDay(), addYear(), etc.

These convenience methods have the same equivalent functionality as the basic operation methods, but expect string and integer $date operands containing only the values representing the type indicated by the suffix of the convenience method. Thus, the names of these methods (e.g. "Year" or "Minute") identify the units of the $date operand, when $date is a string or integer.

The following basic operations do not have corresponding convenience methods for the date parts listed in Section 8.4, “Zend_Date API Overview” .

Several methods support retrieving values related to a Zend_Date instance.

Several methods support retrieving values related to a Zend_Date instance.

Three methods provide access to geographically localized information about the Sun, including the time of sunrise and sunset.