format_date() doesn't return localized year correctly
sugree - December 21, 2007 - 05:01
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Description
format_date() implements most formats using gmdate and use t() to localize month and day manually. It works in most countries but not work well in Thailand since Thailand uses Buddhist era. Usually, we have to call setlocale(LC_TIME, 'th_TH.UTF8') and call strftime('%Ey') to obtain the correct year in Buddhist era, e.g., 2007 = 2550.
I modified common.inc to handle 'Y' and 'y' manually using strftime('%Ey', $timestamp). It works as expect. Note that buddhist era must be used in government agencies in Thailand so it is important to apply this patch for workaround.
There are 2 patches for Drupal 5 and Drupal 6. Actually, they are similar.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| locale-year-5.diff | 604 bytes | Ignored | None | None |
| locale-year-6.diff | 667 bytes | Ignored | None | None |
#1
Hi Sugree,
I couldn't find an %E flag on the strftime doc.
At the same time, the needs of users in Thailand and other Bhuddist countries should be covered at least in Drupal 6. So we need to have this fixed in the next Release Candidate!
Does the patch I enclose work for you?
#2
Can we "hook" with this other calendars as well. Or they are included already?
http://en.wikipedia.org/wiki/Buddhist_calendar
http://en.wikipedia.org/wiki/Indian_national_calendar
As I see the Indian calendar is also used by Government of India. And there are more types of Buddhist calendar.
Can you give me a little example how this patch works?
#3
No, it returns "2007". For "%EY" and "%Ey", I found in POSIX strftime() and it works well in Thailand. Most of us use %EY but some people solve this problem by hardcode adding 543 to 2007 to obtain 2550.
#4
@Pasqualle
Sure! My patch above relies on system locale which may be set by setlocale(LC_CTIME, 'th_TH.UTF8') in settings.php. That means for India, you just need to call setlocale(LC_CTIME, 'ar_IN.UTF8') instead.
Anyway, I found another effect right now. format_date() is also called to format the date in input field. Passing 2550 to strtotime() will result in invalid date because strtotime() doesn't recognize locale year. So handling Y and y for locale year might be not a good idea.
What if we use another character for locale year, e.g., "X" or "c"? And then let users define custom date/time format to replace "Y" by the new one?
Another option is to write drupal_strtotime() which replace %EY by %Y before calling strtotime() as usual.
Any comment?
#5
I found better solution by adding 'X' and 'x' for locale year and let users specify custom date format in settings.php. As a result, date in most pages displays correctly. I applied this new patch to http://drupal.in.th/ and it works without annoying issue.
setlocale(LC_TIME, 'th_TH.UTF8');$conf = array(
'date_format_short' => 'm/d/X - H:i',
'date_format_large' => 'l, F j, X - H:i',
'date_format_medium' => 'D, m/d/X - H:i',
);
There are still issue regarding date input format but replacing strtotime() seems like a big effort.
#6
It would be nice to have this patch in Drupal 6 timeframe. Is it possible?
#7
Drupal never supported non-latin date formats. If we add support for it in Drupal 6, it does not make this a critical issue, neither it makes it a bug. This is a task against Drupal 6, which if I would be more honest would be a feature request.
Reflecting on the latest patch, you introduce X as a non-standard proprietary Drupal extension to the list of format chars from http://php.net/manual/en/function.date.php which we use otherwise. What if PHP introduces an X here?
#8
@Gábor
Good point. If PHP introduces X, they just conflict. date() itself does not support locale date format so there is no systematic approach to extend format chars like %EY in strftime(). So I need to find better approach.
1. Adding a special prefix % to interpret %Y and %y using strftime() to obtain localized year.
2. Changing format chars based on date() to strftime() instead.
#9
Moving this to the D7, cause it won't be fixed in D6 anymore.
#10
+1 (and subscribing to this).
It's really something that should be fixed in D7. Having a localized website, but all the dates in another language/system is quite odd.. I'll look at the patch when I get the time.
#11
I think php considers different eras to be a calendar issue rather than date. See http://www.php.net/manual/en/refs.calendar.php .
If it is merely a case of adding 543 to the year, this might seem overkill, but there are other calendars supported that are more complex.
If such a calendar is configured on the server, would the date API handle the calendar conversions?
#12
subscribe - I don't have any quick solution, but I'm interested to see where this goes.
#13
Patch doesn't apply.
#14
I'm also interested in this issue as well. The other one I posted might be duplicated with this one. http://drupal.org/node/424104
#15
Looks like this needs to be re-thought, due to changes in format_date from #243129: Refactor format_date() to avoid multiple calls to date_format().