repo_zf1/documentation/manual/en/module_specs/Zend_Date-Theory.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<sect1 id="zend.date.definition.theory">

    <title>Theory of Operation</title>

    <para>
        Why is there only one class <classname>Zend_Date</classname> for handling dates and times in the Zend Framework?
    </para>

    <para>
        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 <classname>Zend_Date</classname> 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.
    </para>

    <sect2 id="zend.date.theory.internals">

        <title>Internals</title>

        <para>
            <itemizedlist mark='opencircle'>
                <listitem>
                    <para>
                        UNIX Timestamp
                    </para>
                    <para>
                        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/UTC. This was only possible, because
                        <classname>Zend_Date</classname> 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.
                    </para>
                </listitem>
                <listitem>
                    <para>
                        Date parts as timestamp offsets
                    </para>
                    <para>
                        Thus, an instance object representing three hours would be expressed as three hours after
                        January 1st, 1970 00:00:00 GMT/UTC -i.e. 0 + 3 * 60 * 60 = 10800.
                    </para>
                </listitem>
                <listitem>
                    <para>
                        PHP functions
                    </para>
                    <para>
                        Where possible, <classname>Zend_Date</classname> usually uses PHP functions to improve performance.
                    </para>
                </listitem>
            </itemizedlist>
        </para>

    </sect2>

</sect1>
<!--vim:se ts=4 sw=4 et:-->