Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Date Component Proposal

Proposed Component Name Zend_Date
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Date
Proposers Thomas Weidner
Gavin (Zend-liaison)
Revision 2.0 - 21 July 2006: Reworked proposal ( changed almost everything )
1.0 - 11 Juni 2006: Initial proposal (wiki revision: 23)

Table of Contents

1. Overview

Zend_Date is the basic library for the handling of all date, time and calendar-related issues.

2. References

Mailing List

Date and Time related links

Java

Python

Ruby

Calendars

3. Component Requirements, Constraints, and Acceptance Criteria

  • Wrapper functionality
  • Lightweight and fast implementation
  • Conversion between different locales for date / time
  • Conversion between different calendar-formats
  • Formatting for date, time, calendar using locales

4. Dependencies on Other Framework Components

5. Theory of Operation

Basics

Zend_Date is a basic wrapper for all date, time functions. It implements also calendar
and some other additional functionality.

Locale aware

Zend_Date formats the output with locales. It can output the standard format for different uses f.e. ISO date,
unix timestamp, SQL dateformat, ...
Zend_Date also can convert between different date / time formats and locales

Calendar functions

Zend_Date can convert between and display in different calendar formats. Julian, Gregorian and so on...

Computed functions

Dates can be added or substracted from other dates. Also a difference between dates can be computed

Standards

Zend_Date has to be aware of the following standards.

  • ISO 8601 - Date Time Definition
  • RFC 3339 - Internet Date/Time
  • RFC 822 - Arpa Mail Format (Date/Time)

6. Milestones / Tasks

zone: Missing {zone-data:milestones}

7. Class Index

  • Zend_Date_Exception
  • Zend_Date

8. Use Cases

Define actual Date

Define Date where Input is an ISO Date

Define Date with Unix Timestamp

Define Date where Input is an Locale Defined Datestring

Define Date where Input is an Arab Date

Convert Date to Unix Timestamp

Convert Date to ISO Format

Get actual monthname

Print date formatted with actual locale

Print date formatted with specified locale

9. Class Skeletons

REALISATION

To mention here:

The functions are not to realize as they were shown, instead almost all are aliases for general functions.
In real the realization will look like this :

So the implementation itself will be very small.
Of course we could also do

I think there's no difference in the speed.

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 21, 2006

    <p>A date manipulation and calculation class is a must - I do like the proposal.</p>

    <p>I'd be wary of too many specific translators, though like toSQL() or toIslamic() or fromChinese(). Could these be better implemented with flags passed to a more generic function?</p>

    <p>$date = new Zend_Date;<br />
    $date->fromDate($myvalue, Zend_Date::CALENDAR_CHINESE);<br />
    echo $date->toDate(Zend_Date::CALENDAR_HEBREW);</p>

    <p>I'd also like to see some sort of day/hour/minute manipulation similar to MySQL's TO_DAYS() function which can be very handy when comparing time spans.</p>

    1. Jun 21, 2006

      <p>toIslamic, toChinese and so on are meant to be calendar translation classes.</p>

      <p>Yes, i will change this to</p>

      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      public function toDate($date, $calendar, $format, $locale);
      public function fromDate($date, $calendar, $format,
      ]]></ac:plain-text-body></ac:macro>

      <p>It sounds clearer.</p>

      <p>For comparing Timespans you could do</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $date = new Zend_Date(); // sets todays datestamp
      $date2 = new Zend_Date('23.06.2006 12:00:00.000');
      $difference = $date->compare($date2);
      ]]></ac:plain-text-body></ac:macro>

      <p>For easier handling we should also add functions like</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      public function toDays(){} // outputs number of days from 00.00.0000 00:00:00.000 or a given date
      public function toMonths(){} // outputs number of months from 00.00.0000 00:00:00.000 or a given date
      public function toYears(){} // outputs number of years from 00.00.0000 00:00:00.000 or a given date
      public function toSeconds(){} // outputs number of seconds from 00.00.0000 00:00:00.000 or a given date
      public function toMSec(){} // outputs number of milliseconds from 00.00.0000 00:00:00.000 or a given date
      public function toHour(){} // outputs number of hours from 00.00.0000 00:00:00.000 or a given date
      public function toMinutes(){} // outputs number of minutes from 00.00.0000 00:00:00.000 or a given date
      ]]></ac:plain-text-body></ac:macro>

      <p>But maybe this should also be done like this</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      public function toValue($date, $output) {} // $output could be Zend_Date::MINUTES
      ]]></ac:plain-text-body></ac:macro>

  2. Jul 02, 2006

    <p>Why can't you create an interface for the date conversions? This would allow someone to extend the interface to allow for more date conversions, won't clutter up the main class with so many constants, and make for longer testing and development cycle.</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    interface Zend_Date_iDateConversion {
    // Accepts the date for conversion and the type for checking
    public function from($date, $type);
    public function convertTo($calendar, $locale, $format); // returns the converted date
    ]]></ac:plain-text-body></ac:macro>

    <p>Very simple prototype for the interface, would probably need more methods for the conversions. Would need methods for class to object accepting conversions.</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    class Zend_Date_HebrewCalendar implements Zend_Date_iDateConversion {
    /**

    • Constants for Class here
      */

    public function from($date, $type) { }
    public function convertTo($calendar, $locale, $format) { }
    ]]></ac:plain-text-body></ac:macro>

    1. Jul 03, 2006

      <p>This could be problematic :</p>

      <p>What do you mean with "many constants"... there are only a 8 known calendar formats.</p>
      <ul>
      <li>Gregorian</li>
      <li>Julian</li>
      <li>Buddhist</li>
      <li>Chinese</li>
      <li>Hebrew</li>
      <li>Islamic</li>
      <li>Islamic Civil</li>
      <li>Japanese<br />
      (and maybe some ancient ones which make no sense in my eyes)</li>
      </ul>

      <p>As Zend_Date has to use Zend_Locale, where these Calendar-Formats are defined in the LDML, it would make no sense to allow an interface to extend the class, as the extension would also have to extend the Zend_Locale and the LDML.</p>

      <p>There will be an internal class Zend_Date_Calendar where all this functions will reside, maybe also an Abstract layer (hav'nt thought about this 'til now), but these will not be public as for compatibility with LDML and Zend_Locale.</p>

  3. Jul 17, 2006

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Feedback</ac:parameter><ac:rich-text-body>
    <p>Zend_Date is conditionally accepted subject to the conventions,<br />
    stipulations, requirements, and changes listed below.</p>

    <p>A ZF default locale object should be used in most places where a<br />
    component or function expects an optional locale object.<br />
    The default locale object should be constructed from an instance of<br />
    Zend_Config shared by all ZF components.</p>

    <p>The Zend_Date API should not preclude the addition of a class to<br />
    manage timestamps or a class to manage only dates, should these<br />
    prove necessary for resource or performance reasons. Note that<br />
    some functions become more complicated when using only one class<br />
    for dates and times, including validating dates and times.</p>

    <p>Since Zend_Date offers combined date and time functionality,<br />
    we suggest renaming the class to Zend_DateTime.</p>

    <p>Add to the requirements: Functionality in Zend_Date that duplicates<br />
    the new object-oriented date extension (due in PHP 5.2?) will be<br />
    replaced when available in the default installation of the minimum<br />
    version of PHP required by ZF. Effort should be made to provide<br />
    wrapper functionality and a compatible API for areas of Zend_Date<br />
    that overlap. Please search for occurrences of PHP_FUNCTION in:
    <a class="external-link" href="http://lxr.php.net/source/php-src/ext/date/php_date.c">http://lxr.php.net/source/php-src/ext/date/php_date.c</a>
    <a class="external-link" href="http://derickrethans.nl/files/time-qc2006.pdf">http://derickrethans.nl/files/time-qc2006.pdf</a></p>

    <p>Zend_Date should be able to output RFC 822 formatted dates.</p>

    <p>What is the rationale behind choosing to combine all date and time<br />
    related functionality into one class like .NET instead of like Ruby?</p>

    <p>$date = '143465234'; // Input date in Unix Timestamp Format<br />
    $dateobj = Zend_Date($date,Zend_Date::UNIX);</p>

    <p>The use of constants instead of function names (e.g. toValue($date,<br />
    Zend_Date::MINUTES) is non-standard amongst most popular languages. We<br />
    prefer to avoid overuse of constants, where common function names are<br />
    shared by numerous languages for performing the same date-related<br />
    tasks. Consider using one function to compute time spans, and others to<br />
    return the number of months, years, minutes, seconds, etc. in the<br />
    resulting time span.</p>

    <p>Instances should be serializable.</p>

    <p>NTP functions should be split to a different class that is not<br />
    required by default.</p>

    <p>Parsing, normalization, conversion, and formatting function names<br />
    could benefit from sharing common looking names with other locale-related<br />
    classes.</p>

    <p>No toSQL(). The Db Adapter should have a public function accepting a<br />
    Zend_Date object for conversion to the correct format for the DB.</p></ac:rich-text-body></ac:macro>

    1. Jul 21, 2006

      <blockquote>
      <p>A ZF default locale object should be used in most places where a<br />
      component or function expects an optional locale object.<br />
      The default locale object should be constructed from an instance of<br />
      Zend_Config shared by all ZF components.</p></blockquote>
      <p>All parameters which expect locale are OPTIONALLY.<br />
      When this parameter is not given, the locale is taken from the<br />
      standard locale which is defined by the ZF (Browser, Environment or Config)</p>
      <blockquote>
      <p>The Zend_Date API should not preclude the addition of a class to<br />
      manage timestamps or a class to manage only dates, should these<br />
      prove necessary for resource or performance reasons. Note that<br />
      some functions become more complicated when using only one class<br />
      for dates and times, including validating dates and times.</p></blockquote>
      <p>I do not preclude anything <ac:emoticon ac:name="smile" /><br />
      For now I don't see any reason to split the functions.<br />
      Maybe later on when far more development is done and we are seeing<br />
      that there is a preformance bonus when splitting them.<br />
      Now it's too early to say which is better.</p>

      <p>But I think DOT NET and JAVA had thought hard befor they made their<br />
      decision for only a DATE-Class. And I dont think that they were wrong.</p>
      <blockquote>
      <p>Since Zend_Date offers combined date and time functionality,<br />
      we suggest renaming the class to Zend_DateTime.</p></blockquote>
      <p>To think of it...<br />
      Java and Dot Net are both using only a Date-Object instead of renaming it to DateTime.<br />
      Both Date-Objects also offer time functionallity, as time is a subset of date.</p>

      <p>And second...<br />
      Maybe Zend_Calendar could also be a good decision. Take a look at JAVA.<br />
      Personally I think that Zend_Date is more descriptive than Zend_DateTime.</p>
      <blockquote>
      <p>Add to the requirements: Functionality in Zend_Date that duplicates<br />
      the new object-oriented date extension (due in PHP 5.2?) will be<br />
      replaced when available in the default installation of the minimum<br />
      version of PHP required by ZF. Effort should be made to provide<br />
      wrapper functionality and a compatible API for areas of Zend_Date<br />
      that overlap. Please search for occurrences of PHP_FUNCTION in:<br />
      <a href="http://lxr.php.net/source/php-src/ext/date/php_date.c">http://lxr.php.net/source/php-src/ext/date/php_date.c</a><br />
      <a href="http://derickrethans.nl/files/time-qc2006.pdf">http://derickrethans.nl/files/time-qc2006.pdf</a></p></blockquote>
      <p>Yes... that's complete clear.<br />
      As I see, with PHP5.2 most of the expected issues we want to do, are<br />
      direct avaiable through PHP itself in standard installation.</p>

      <p>The only question is when will the requirements for the framework<br />
      be updated to use PHP5.2 ?</p>

      <p>I don't think that it's a good approach to detect the PHP Version and<br />
      act properly... own functions when <5.2... wrapper when >=5.2<br />
      This would make no sense in my eyes for performance reasons.</p>

      <p>So as I see, we will have to integrate functionallity for now and<br />
      change this to wrap the php5.2-date object.<br />
      Functions will be so done that with PHP5.2 wrapping could be done,<br />
      with almost not much work.</p>
      <blockquote>
      <p>Zend_Date should be able to output RFC 822 formatted dates.</p></blockquote>
      <p><a href="http://www.w3.org/Protocols/rfc822/#z28">http://www.w3.org/Protocols/rfc822/#z28</a><br />
      shows the datetime definition for the RFC822 Arpa Mail Format<br />
      Prinzipially the output format could be choosen complete free.<br />
      Zend_DateTime->format($format);<br />
      But the most used and known formats will be predefined.<br />
      f.e. Zend_DateTime::RFC822 = 'DDD, DD.MM.YYYY hh:mm:ss' or so.<br />
      Zend_DateTime->toString(Zend_DateTime::RFC822); would output a proper RFC822<br />
      compilant date string.</p>
      <blockquote>
      <p>What is the rationale behind choosing to combine all date and time<br />
      related functionality into one class like .NET instead of like Ruby?</p></blockquote>
      <p>See Pear-Date Class<br />
      <a href="http://pear.php.net/reference/Date-1.4.2/Date/Date.html">http://pear.php.net/reference/Date-1.4.2/Date/Date.html</a><br />
      See Java Date Class<br />
      <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html">http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html</a></p>

      <p>I think it is more naturally to let date and time side by side instead of<br />
      splitting them in 3 seperated classes.</p>
      <blockquote>
      <p>The use of constants instead of function names (e.g. toValue($date,<br />
      Zend_Date::MINUTES) is non-standard amongst most popular languages. We<br />
      prefer to avoid overuse of constants, where common function names are<br />
      shared by numerous languages for performing the same date-related<br />
      tasks. Consider using one function to compute time spans, and others to<br />
      return the number of months, years, minutes, seconds, etc. in the<br />
      resulting time span.</p></blockquote>
      <p>That's already reworked in a previous version of the proposal.<br />
      It's now preffered to have several functions<br />
      ->getHour ->getMinute<br />
      to become details. All the functions are aliases for a global function ->get<br />
      Now with the reworking all common functions from other languages<br />
      should be present in Zend_DateTime.</p>
      <blockquote>
      <p>Instances should be serializable.</p></blockquote>
      <p>I added this</p>
      <blockquote>
      <p>NTP functions should be split to a different class that is not<br />
      required by default.</p></blockquote>
      <p>Should I extract NTP-functionallity to an extra proposal ? (preffered i think)<br />
      Or is it enough to make just an extra class Zend_DateTime_NTP ? (makes no sense in my eyes)</p>
      <blockquote>
      <p>Parsing, normalization, conversion, and formatting function names<br />
      could benefit from sharing common looking names with other locale-related<br />
      classes.</p></blockquote>
      <p>All parsing, normalization and formatting functionallity is done by<br />
      Zend_Locale_Format. So all functions are shared with other ZF classes.</p>
      <blockquote>
      <p>No toSQL(). The Db Adapter should have a public function accepting a<br />
      Zend_Date object for conversion to the correct format for the DB.</p></blockquote>
      <p>toSQL was erased a couple of versions ago. There's no need for this spezial<br />
      functionallity. To format a date object in a proper format someone could do<br />
      Zend_DateTime->format($format); and choose the needed formating-rules.</p>

      <hr />
      <p>So... I reworked almost the complete proposal to get all points mentioned by you.</p>

      <p>Hope I didn't forget something <ac:emoticon ac:name="cheeky" /></p>

      <p>Greetings<br />
      Thomas</p>

      1. Jul 25, 2006

        <p>Thomas, I think it looks great.</p>

        <p>I have some more comments that are notes I would like to save here for future reference:</p>

        <hr />

        <p>Perl and Java combine date and time into one class. Ruby and Python distinguish between calandar dates and simple times. I believe "aware" datetime's reduce the benefits gained by distinguishing using different classes.</p>

        <p>Working with calendar dates involves different data and functionality than manipulation of times of the day. Often, we need to work with one or the other, but not both in the same object. I'm less concerned about performance than I am about the complexity of the API.</p>

        <p>The word "date" in various languages often means date and time, but not always (see <a class="external-link" href="http://docs.python.org/lib/node251.html">http://docs.python.org/lib/node251.html</a> and <a class="external-link" href="http://www.ruby-doc.org/core/classes/Date.html">http://www.ruby-doc.org/core/classes/Date.html</a>). The words "hour", "minute", and "second" do not appear in the definition of the word "date" (<a class="external-link" href="http://www.answers.com/date">http://www.answers.com/date</a>).</p>

        <p>I'm not convinced that the ZF will never have a class implementing only support for dates without times. If this pure-date class exists, what should it be called?</p>

        <p>Yes, I completely agree with "integrate functionality for now and change this to wrap the php5.2 date object" when it becomes available, and the minimum version of the framework is upgraded.</p>

        <blockquote><p>Should I extract NTP-functionallity to an extra proposal ? (preffered i think)</p></blockquote>

        <p>Yes, that sounds good.</p>

        1. Jul 27, 2006

          <blockquote>
          <p>I'm not convinced that the ZF will never have a class implementing only support for dates without times. If this pure-date class exists, what should it be called?</p></blockquote>
          <p>When we would have to split the class I would do it like this:</p>

          <p>Zend_Time // Only Time<br />
          Zend_Date extends Zend_Time // Date (and Time if needed)<br />
          Zend_Calendar extends Zend_Date // Complete Calendar functionallity</p>
          <blockquote>
          <p>Yes, I completely agree with "integrate functionality for now and change this to wrap the php5.2 date object" when it becomes available, and the minimum version of the framework is upgraded.</p></blockquote>
          <p>I'm not sure if the date-object covers all things I've written in my proposal with Version 5.2. I took a look in about 6-8 different languages and date implementations and wrote them all together, so that all need should be covered <ac:emoticon ac:name="wink" /><br />
          /me will first make the other proposals ready... maybe /me has then less work than now, as a PHP5.2 prerelease is already avaiable. <ac:emoticon ac:name="laugh" /> /me holds his thumbs <ac:emoticon ac:name="cheeky" /></p>
          <blockquote>
          <p>Should I extract NTP-functionallity to an extra proposal ? (preffered i think)</p>

          <p>Yes, that sounds good.</p></blockquote>
          <p>/me banging his head on the floor <ac:emoticon ac:name="cheeky" /></p>

          <p>Ahrrr.... could anyone do this ? I've so much to do with my 4 proposals that I am not able to do a 5th one <ac:emoticon ac:name="wink" /></p>

  4. Jul 25, 2006

    <p>I've got a quick question regarding the constants you're passing to and from the Zend_Date object.</p>

    <p>I notice in your examples there is a lot of:-</p>

    <p>echo $dateobj->getMonth('Zend_Date::MONTHNAME',Zend_Date::DE_DE);</p>

    <p>Where DE_DE is a constant of Zend_Date. But how can we perform the same sort of operation to find the value of 'EN_UK' or 'EN_AU' if it is passed as a variable?</p>

    <p>e.g. </p>

    <p>$to = 'EN_AU';<br />
    $from = 'DE_DE';</p>

    <p>How can I determine the correct locale value to pass to the getMonth method this way? I'd obviously prefer to have the flexibility not to hard-code constants into my code if they're not strictly necessary.</p>

    1. Jul 26, 2006

      <blockquote>
      <p>I notice in your examples there is a lot of:-</p>

      <p>echo $dateobj->getMonth('Zend_Date::MONTHNAME',Zend_Date::DE_DE);</p>

      <p>Where DE_DE is a constant of Zend_Date. But how can we perform the same sort of operation to find the value of 'EN_UK' or 'EN_AU' if it is passed as a variable?</p>

      <p>e.g.</p>

      <p>$to = 'EN_AU';<br />
      $from = 'DE_DE';</p></blockquote>
      <p>I've forgot to change the examples when I renewed the class skeleton.</p>

      <p>First:<br />
      getMonth will only return a number representation of the month, and this is locale-independent<br />
      When you look at the class skeleton you will also see that getMonth has no parameters.</p>

      <p>Zend_Date has no known locales.<br />
      So instead of Zend_Date::de_DE is should be Zend_Locale::de_DE.</p>

      <p>When you want a month name, which is locale dependent, you can do something like this:</p>

      <p>Output the actual month in standard locale</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $date = Zend_Date();
      echo $date->getMonthName();
      ]]></ac:plain-text-body></ac:macro>
      <p>Output in different locale (f.e. fr_FR)</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $date = Zend_Date();
      echo $date->getMonthName(Zend_Locale::fr_FR);
      ]]></ac:plain-text-body></ac:macro>
      <p>Input date in a different Locale</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $date = Zend_Date($datestring, Zend_Locale::de_DE);
      echo $date->getMonthName(Zend_Locale::fr_FR);
      ]]></ac:plain-text-body></ac:macro>
      <blockquote>
      <p>How can I determine the correct locale value to pass to the getMonth method this way? I'd obviously prefer to have the flexibility not to hard-code constants into my code if they're not strictly necessary.</p></blockquote>
      <p>You don't have to set a locale. All locale-parameters are OPTIONAL !!<br />
      Zend_Date will know the standard locale and use it.</p>

      <p>When your user uses a different locale you will have to do something like this:</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $userlocale = Zend_Locale::getDefaultBrowserLocale();
      ... // Let the user select which locale to use or select it automatically
      $locale = new Zend_Locale($userlocale[$selected]);
      ... // Set a different locale than the standard one

      $date = new Zend_Date(); // actual Date/Time
      echo $locale->_("This month is %1\$s",$date->getMonthName());
      echo $locale->_("In french this month is %1\$s",$date->getMonthName(Zend_Locale::fr));
      ]]></ac:plain-text-body></ac:macro>
      <p>Btw:<br />
      Zend_Locale will have a function to let you determinate which locales are avaiable for translation.<br />
      Something like this:<br />
      Zend_Locale_Data::getRegionList<br />
      Zend_Locale_Data::getLocaleList<br />
      Zend_Locale->getAvaiableLocales</p>

      <p>But all month names will be present for all locales independent from the avaiable translations, as these strings are in LDML.<br />
      So you could always do a ->getDayName($locale); even when you have no translation for this locale avaiable.</p>

      1. Jul 26, 2006

        <p>Thanks Thomas - I understand setting the locale isn't mandatory. My question was based more around the use of constants for the date methods.</p>

        <p>So are you saying that the following will still be valid?</p>

        <p>$data = new Zend_Date();<br />
        $locale = new Zend_Locale('fr_FR');<br />
        echo $date->getMonthName($locale);</p>

        1. Jul 27, 2006

          <p>Yes, that will be valid.</p>

          <p>Of course when you make</p>
          <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
          $locale = new Zend_Locale('fr_FR');
          ]]></ac:plain-text-body></ac:macro>
          <p>you will set 'fr_FR' as you new locale.</p>

          <p>So you could do</p>
          <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
          echo $date->getMonthName();
          ]]></ac:plain-text-body></ac:macro>
          <p>and your set default locale will be used.<br />
          It will be the same it you would have written</p>
          <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
          echo $date->getMonthName($locale);
          ]]></ac:plain-text-body></ac:macro>
          <p>You will only have to set a spezified locale when you want to create a defined output in a different locale than the one the user sees.</p>

          <p>For example when you have a xml file and will write your datas and output in english, independent which language the user has set.<br />
          So you could show the user the date in his language and write the same date in a spezified different language.</p>

          <p>It's just an idea.</p>

          <p>What I really wanted to say is, that you will have the <strong>OPTION</strong> to set a different locale/language for display when you are in need of it, but its <strong>NEVER NECESSARY</strong> to use it, as our system will detect it automatically in almost all common use cases.</p>