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

wants to merge 1 commit into


None yet
2 participants

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.

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.


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.


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.


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).


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.


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!


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.


bar commented May 30, 2011

In case everything else is good to go:

Fixed and rebased to 1.3 branch from today

@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