Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Fix for bad encoded strftime() values when LC_TIME has code points higher than 128 #27

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
Contributor

bar commented Jan 11, 2011

@bar bar Fix for helper functions not returning a valid utf8 string when LC_TIME
file has characters represented by unicode code point higher than 128.
Also harden tests.
(http://cakephp.lighthouseapp.com/projects/42648-cakephp/tickets/912)
01f6c81
Contributor

bar commented Mar 23, 2011

Inside testI18nFormat() test failure is not evident because test case it is not tight enough, If you put a multibyte character inside the test, for example, if you change the line [1] for [2], the actual cake test will fail:

[1] $expected = 'jue 14 ene 2010 13:59:28 ' . strftime('%Z', $time);

[2] $expected = 'mié 13 ene 2010 13:59:28 ' . strftime('%Z', $time);

notice the accented 'é' in the string.

Owner

markstory commented May 29, 2011

Why does FormHelper need to change as well? The formatting there doesn't go through the i18n class, so I don't really understand why that changed as well.

Contributor

bar commented May 29, 2011

Yes, I know Mark, but a call to Form::i18nFormat for example, should return a correct value, but strftime fails to do so, that was the main problem when formatting dates trough the form helper.

If Form helper does not change, calls to Multibyte::strftime will work well but calls to Form methods where strftime is used instead of the multibyte version will fail I guess.

Contributor

bar commented May 30, 2011

Sorry Mark, when I wrote Form::i18nFormat I meant Form::dateTime , my bad!

Also Form->__generateOptions() has a call to strftime() which means every other method calling this private function is affected, this being almost every Form method.

Maybe changing those strftime() calls from FormHelper to some other static call inside a TimeHelper multibyte strftime() wrapper function can isolate things a bit... hope this helps (if there is no other way to circumvent this).

Owner

markstory commented May 30, 2011

Sure, but how does '%Y-%m-%d %H:%M:%S' get multibyte characters? This is an all numeric dateformat, I don't see why it has to incur the extra overhead of going through Multibyte, when it will never happen.

Contributor

bar commented May 30, 2011

Ohh gosh, you are damn right Mark! I haven't payed attention to both being all numeric strings.
Every change made by this patch inside FromHelper can be thrown away :)

Thanks for the insight!

Contributor

bar commented May 30, 2011

Ohh, if you need me to fix the patch and update it to 1.3.9 for a proper review, please punch me here and I will.

Contributor

bar commented May 30, 2011

In case everything else is good to go:

Fixed and rebased to 1.3 branch from today
bar/cakephp@fc4de67

@bar bar closed this Jun 1, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment