Hi!

We just solved a problem for us that I think all non-English users of silverstripe have: The Date Fieldtype uses the php function date(), which does not respect the setlocale settings:

//sapphire/core/model/fieldtypes/Date.php
if($this->value) return date($formattingString, strtotime($this->value));

Output: "February 2008" on a German computer.

Instead we use strftime:

if ($this->value) return strftime($formattingString, strtotime($this->value));

Output: "Februar 2008".

Is there any matter why date() is used? Otherwise I would propose to change this or to add a function strftime.

Cheers,

Andy

This seems like a reasonable change. Can you submit a patch to http://open.silverstripe.com?

Yes, of course! As this is my first patch for silverstripe: This is a Patch for "Core" against the trunk (aka 2.2.2RC3) for Milestone 2.2.3, component "Sapphire Framework", right? I will check, whether there are other places where date() is used.

Ah, what do you prefer? A general change towards strftime would require to change any format strings, as the syntax is different ("d.m.Y" vs. "%d.%m.%Y"). I still would prefer this as the standard way to format dates in silverstripe should be localized (hmm, does the word "localizable" exist?). I would track all uses of format strings in the core and in modules (I think mainly the blog module) and change them.

The alternative would be an additional function strftime().

Cheers,

Andy

A better solution would probaply be just adding a function called "LocalFormat" or something, which would wrap strftime as described.
This wouldn't break compatibility and features like pre-formatted ISO dates (which strftime doesn't currently supply) wouldn't be gone.

Hi,
Thank you very much your code helped a lot but,
I think you should consider to add a utf8_encode() this way:

function LocalFormat($formattingString) {
		if($this->value) return utf8_encode(strftime($formattingString, strtotime($this->value)));
	}