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 or 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
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).
Example 165. User-Specified Input Date 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"
// strictly restricts interpretation to specified format
$date3 = new Zend_Date('Feb 31, 2007', 'MM.dd.yyyy');
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.
Since Zend Framework 1.7.0 Zend_Date does also support the usage
of an application wide locale. You can simply set a Zend_Locale
instance to the registry like shown below. With this notation you can forget about
setting the locale manually with each instance when you want to use the same locale
multiple times.
<?php
// in your bootstrap file
$locale = new Zend_Locale('de_AT');
Zend_Registry::set('Zend_Locale', $locale);
// somewhere in your application
$date = new Zend_Date('31.Feb.2007');