Theory of Operation
Why is there only one class Zend_Date for handling dates and times in
Zend Framework?
Many languages split the handling of times and calendar dates into two classes. However,
Zend Framework strives for extreme simplicity, and forcing the developer to manage different
objects with different methods for times and dates becomes a burden in many situations.
Since Zend_Date methods support working with ambiguous dates that
might not include all parts (era, year, month, day, hour, minute, second, timezone),
developers enjoy the flexibility and ease of using the same class and the same methods to
perform the same manipulations (e.g. addition, subtraction, comparison, merging of date
parts, etc.). Splitting the handling of these date fragments into multiple classes would
create complications when smooth interoperation is desired with a small learning curve. A
single class reduces code duplication for similar operations, without the need for a complex
inheritance hierarchy.
Internals
-
UNIX Timestamp
All dates and times, even ambiguous ones (e.g. no year), are represented
internally as absolute moments in time, represented as a UNIX
timestamp expressing the difference between the desired time and
January 1st, 1970 00:00:00 GMT. This was only possible,
because Zend_Date is not limited to
UNIX timestamps nor integer values. The BCMath extension is
required to support extremely large dates outside of the range
Fri, 13 Dec 1901 20:45:54 GMT to
Tue, 19 Jan 2038 03:14:07 GMT. Additional, tiny math
errors may arise due to the inherent limitations of float data types and
rounding, unless using the BCMath extension.
-
Date parts as timestamp offsets
Thus, an instance object representing three hours would be expressed as
three hours after January 1st, 1970 00:00:00 GMT
-i.e. 0 + 3 * 60 * 60 = 10800.
-
PHP functions
Where possible, Zend_Date usually uses
PHP functions to improve performance.
|
|