Problem with Zend_Date::setDate and locales

[Dermot]

Hi all,

I'm having some problems with the following code (this is a simplified  
version):

                $dt = new Zend_Date();
                $dttemp = new Zend_Date('2008-06-24', Zend_Date::ISO_8601);
                $dt->setDate($dttemp);

The above works as expected when the client and the server have the  
same locale (in my case that's 'en_IE'), but it fails at setDate()  
when the client has the 'sv_SE' locale (and possibly others), giving  
the error:

                Unable to parse the date format string 'EEEE'en' 'den' d:'e' MMMM  
yyyy' at letter 'n'

I know I can work around this by specifying a (working) locale for the  
first date ($dt), in which case it doesn't default to the client  
locale, and all works as expected; but I'm wondering if this should be  
considered a bug with Zend_Date::setDate?


Note: you can reproduce the error without changing your locale by  
simply specifying the locale for $dt, ie.

                $dt = new Zend_Date(null, null, 'sv_SE');




Appreciate any help on this,

Dermot.

[thomasW]

By using
->setDate($date);
you say that your input date is formatted according to your browsers, or
your servers locale because you have not set a locale yourself to work with.

When you expect or have a fixed locale in your input you should also set it.
->setDate($date, $locale);
otherwise you are saying that the system must use the default locale. This
is noted within the API doc.

Note:
Input and output are completly seperated from each other. But if you do not
specify they both use the same locale.

And no, this is no bug. :-)

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----
From: "Dermot Buckley" <buckley.d@...>
To: <fw-i18n@...>
Sent: Tuesday, June 24, 2008 2:08 PM
Subject: [fw-i18n] Problem with Zend_Date::setDate and locales

> Hi all,
>
> I'm having some problems with the following code (this is a simplified
> version):
>
> $dt = new Zend_Date();
> $dttemp = new Zend_Date('2008-06-24', Zend_Date::ISO_8601);
> $dt->setDate($dttemp);
>
> The above works as expected when the client and the server have the  same
> locale (in my case that's 'en_IE'), but it fails at setDate()  when the
> client has the 'sv_SE' locale (and possibly others), giving  the error:
>
> Unable to parse the date format string 'EEEE'en' 'den' d:'e' MMMM  yyyy'
> at letter 'n'
>
> I know I can work around this by specifying a (working) locale for the
> first date ($dt), in which case it doesn't default to the client  locale,
> and all works as expected; but I'm wondering if this should be  considered
> a bug with Zend_Date::setDate?
>
>
> Note: you can reproduce the error without changing your locale by  simply
> specifying the locale for $dt, ie.
>
> $dt = new Zend_Date(null, null, 'sv_SE');
>
>
>
>
> Appreciate any help on this,
>
> Dermot.

[Dermot]

Thanks for the reply Thomas.

(Apologies for replying via Nabble, I thought I was subscribed to this list, but it seems I'm not anymore).

thomasW wrote:

By using
->setDate($date);
you say that your input date is formatted according to your browsers, or
your servers locale because you have not set a locale yourself to work with.

When you expect or have a fixed locale in your input you should also set it.
->setDate($date, $locale);
otherwise you are saying that the system must use the default locale. This
is noted within the API doc.

Note:
Input and output are completly seperated from each other. But if you do not
specify they both use the same locale.

And no, this is no bug. :-)

I agree with what you're saying when the argument to setDate() is a string ... but when it's already a valid Zend_Date?

eg.

                $dt1 = new Zend_Date(new Zend_Locale('en_IE'));
                $dt2 = new Zend_Date(new Zend_Locale('sv_SE'));
                $dt2->setDate($dt1);

... throws an exception!

Surely if only the argument to setDate() is a Zend_Date, it should use the argument's locale?

Consider the case when changing from a dd/mm/yyyy to a mm/dd/yyyy locale.  No error, no warning, just an impossible to find bug.

Dermot.

[thomasW]

It uses the arguments locale.
Otherwise it would not even work in the first case.

Your problem is that the CLDR has a problem with the locale sv.

> Unable to parse the date format string 'EEEE'en' 'den' d:'e' MMMM  yyyy'
> at letter 'n'

This is no failure from Zend_Date but from the I18N base component.
It means that the format string which is defined within the sv.xml file is
wrong. 's are not allowed in date strings. As we are using the CLDR as is,
without any changes, except stripped notices, there are a few bugs.
CLDR which is a part of Unicode is working on a new release, but until now
it has not been released.

So there are several ways for you to get rid of this CLDR bug.

* Use a explicit different locale for setDate
* Use a different input method. As you referred that your input is already a
Zend_Date instance you should use setTimestamp instead
* Debug the CLDR source file to the failure does not occur anymore
* Use a different input at setDate by defining it manually

New versions of CLDR are integrated as soon as they are available.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----
From: "Dermot" <buckley.d@...>
To: <fw-i18n@...>
Sent: Tuesday, June 24, 2008 3:14 PM
Subject: Re: [fw-i18n] Problem with Zend_Date::setDate and locales

>
> Thanks for the reply Thomas.
>
> (Apologies for replying via Nabble, I thought I was subscribed to this
> list,
> but it seems I'm not anymore).
>
>
> thomasW wrote:
>>
>> By using
>> ->setDate($date);
>> you say that your input date is formatted according to your browsers, or
>> your servers locale because you have not set a locale yourself to work
>> with.
>>
>> When you expect or have a fixed locale in your input you should also set
>> it.
>> ->setDate($date, $locale);
>> otherwise you are saying that the system must use the default locale.
>> This
>> is noted within the API doc.
>>
>> Note:
>> Input and output are completly seperated from each other. But if you do
>> not
>> specify they both use the same locale.
>>
>> And no, this is no bug. :-)
>>
>
>
> I agree with what you're saying when the argument to setDate() is a string
> ... but when it's already a valid Zend_Date?
>
> eg.
>
> $dt1 = new Zend_Date(new Zend_Locale('en_IE'));
> $dt2 = new Zend_Date(new Zend_Locale('sv_SE'));
> $dt2->setDate($dt1);
>
> ... throws an exception!
>
> Surely if only the argument to setDate() is a Zend_Date, it should use the
> argument's locale?
>
> Consider the case when changing from a dd/mm/yyyy to a mm/dd/yyyy locale.
> No error, no warning, just an impossible to find bug.
>
> Dermot.
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Problem-with-Zend_Date%3A%3AsetDate-and-locales-tp18089626p18090740.html
> Sent from the Zend I18N/Locale mailing list archive at Nabble.com.

[Dermot]

Thanks again for your reply Thomas.  Really appreciate you replying so  
promptly. :)


On 24 Jun 2008, at 16:22, Thomas Weidner wrote:

> It uses the arguments locale.

I'm not entirely certain that that's true.

In 1.5.2 (it may be different in 1.6), setDate() is declared as

        public function setDate($date, $format = null, $locale = null)

So if $locale is not specified, it gets set to null.  This in turn calls

        $this->_date('set', $date, $format, $locale)

with both $format and $locale set to null.

And then in Zend_Date::_date we have ...

         if ($locale === null) {
              $locale = $this->getLocale();
         }

So the locale gets set to the object's own locale, not it's argument.



A quick fix for me here was to change those lines to the following:

         if ($locale === null) {
          if ($date instanceof Zend_Date) {
          $locale = $date->getLocale();
          } else {
                    $locale = $this->getLocale();
          }
         }

i.e. using the argument's locale if argument is a date.



I expect the CLDR stuff is also an issue, but this seems to step  
around it (for me at least).


Dermot.

[thomasW]

What you've patched has nothing to do with the problem at all and it does
even not work properly.
It may work for the case that your server uses "en" and the client uses
"sv".
But it will not work when the server uses "sv" and the client "en".

Related to the code, I think that I am the one who really knows how my own
code works.
When you do not give any locale than the locale from the own instance will
be used.
The locale is only needed to get a proper date-output from the foreign
instance.
When we use the locale from the other instance we have a additional
reparsing which needs additional performance.
Therefor, when you have a date instance it will just ask for a date string
which is formatted like this instance needs it.

Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com

----- Original Message -----
From: "Dermot Buckley" <buckley.d@...>
To: "Thomas Weidner" <thomas.weidner@...>
Cc: <fw-i18n@...>
Sent: Tuesday, June 24, 2008 5:50 PM
Subject: Re: [fw-i18n] Problem with Zend_Date::setDate and locales

> Thanks again for your reply Thomas.  Really appreciate you replying so
> promptly. :)
>
>
> On 24 Jun 2008, at 16:22, Thomas Weidner wrote:
>
>> It uses the arguments locale.
>
> I'm not entirely certain that that's true.
>
> In 1.5.2 (it may be different in 1.6), setDate() is declared as
>
> public function setDate($date, $format = null, $locale = null)
>
> So if $locale is not specified, it gets set to null.  This in turn calls
>
> $this->_date('set', $date, $format, $locale)
>
> with both $format and $locale set to null.
>
> And then in Zend_Date::_date we have ...
>
>         if ($locale === null) {
>             $locale = $this->getLocale();
>         }
>
> So the locale gets set to the object's own locale, not it's argument.
>
>
>
> A quick fix for me here was to change those lines to the following:
>
>         if ($locale === null) {
>         if ($date instanceof Zend_Date) {
>         $locale = $date->getLocale();
>         } else {
>             $locale = $this->getLocale();
>         }
>         }
>
> i.e. using the argument's locale if argument is a date.
>
>
>
> I expect the CLDR stuff is also an issue, but this seems to step  around
> it (for me at least).
>
>
> Dermot.