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(array('format_type' => 'php')).
Afterward, use PHP's date format specifiers for all functions
which accept a $format parameter. Use
Zend_Date::setOptions(array('format_type' => 'iso')) to
switch back to the default mode of supporting only ISO date
format tokens. For a list of supported format codes, see
Self-Defined OUTPUT Formats
Using PHP's date() Format Specifiers
When dates are manipulated, sometimes they cross over a DST
change, normally resulting in the date losing or gaining an hour. For exmaple, when
adding months to a date before a DST change, if the resulting
date is after the DST change, then the resulting date will appear
to lose or gain an hour, resulting in the time value of the date changing. For
boundary dates, such as midnight of the first or last day of a month, adding enough
months to cross a date boundary results in the date losing an hour and becoming the
last hour of the preceding month, giving the appearance of an "off by 1" error. To
avoid this situation, the DST change ignored by using the
fix_dst option. When crossing the Summer or Winter
DST boundary, normally an hour is substracted or added depending
on the date. For example, date math crossing the Spring DST leads
to a date having a day value one less than expected, if the time part of the date
was originally 00:00:00. Since Zend_Date is based on
timestamps, and not calendar dates with a time component, the timestamp loses an
hour, resulting in the date having a calendar day value one less than expected. To
prevent such problems use the option fix_dst, which defaults to
TRUE, causing DST to have no effect on date
"math" (addMonth(), subMonth()).
Use Zend_Date::setOptions(array('fix_dst' => false)) to
enable the subtraction or addition of the DST adjustment when
performing date "math".
If your actual timezone within the instance of
Zend_Date is set to UTC or
GMT the option 'fix_dst' will not be
used because these two timezones do not work with DST.
When you change the timezone for this instance again to a timezone which is not
UTC or GMT the previous set 'fix_dst' option
will be used again for date "math".
When adding or substracting months from an existing date, the resulting value for
the day of the month might be unexpected, if the original date fell on a day close
to the end of the month. For example, when adding one month to January 31st, people
familiar with SQL will expect February 28th as the result. On the
other side, people familiar with Excel and OpenOffice will expect March 3rd as the
result. The problem only occurs, if the resulting month does not have the day, which
is set in the original date. For Zend Framework developers, the desired behavior is
selectable using the extend_month option to choose either the
SQL behaviour, if set to FALSE, or the
spreadsheet behaviour when set to TRUE. The default behaviour
for extend_month is FALSE, providing
behavior compatible to SQL. By default,
Zend_Date computes month calculations by truncating dates to
the end of the month (if necessary), without wrapping into the next month when the
original date designates a day of the month exceeding the number of days in the
resulting month. Use Zend_Date::setOptions(array('extend_month' =>
true)) to make month calculations work like popular spreadsheet
programs.
You can speed up Zend_Date by using an
Zend_Cache adapter. This speeds up all methods of
Zend_Date when you are using localized data. For example all
methods which accept Zend_Date::DATE and
Zend_Date::TIME constants would benefit from this. To set an
Zend_Cache adapter to Zend_Date just
use Zend_Date::setOptions(array('cache' => $adapter)).
Normally the clocks from servers and computers differ from each other.
Zend_Date is able to handle such problems with the help of
Zend_TimeSync. You can set a timeserver with
Zend_Date::setOptions(array('timesync' => $timeserver))
which will set the offset between the own actual timestamp and the real actual
timestamp for all instances of Zend_Date. Using this option
does not change the timestamp of existing instances. So best usage is to set it
within the bootstrap file.