This project is archived and is in readonly mode.
RFC822 shouldn't be localized
Reported by Jérémy Lecour | December 18th, 2008 @ 04:44 PM | in 2.x
Hi,
I've found that a date formatted as RFC822 is localized like any other format, and as far as I can tell this format should not be localized.
I've found the problem when I tried to have my RSS feeds localized in my freshly internationalized app. In english, the "pubDate" is well formed (Wed, 17 Dec 2008 11:07:01 +0100), but in other languages (french by exemple), the date looks like this : "jeu, 18 déc 2008 09:48:34 +0100"
The Feed validator (http://feedvalidator.org/) tells me that the feed is invalid and my RSS agregator (NetNewsWire) is not showing the correct date (the last synced date)
Strangely, this behavour is permanent on a Debian server with Nginx/Mongrel/Rails2.2.2/... but it's not permanent on my local MacBookPro using Passenger. I've struggled quitea long time to stop the localization before I've started to write this ticket, and now it's working with not code change at all.
Maybe there is something wrong on my side. I'm confused.
Comments and changes to this ticket
-
Yaroslav Markin December 18th, 2008 @ 06:18 PM
- Tag set to i18n
Could you please pastie the code that leads to this?
-
Jérémy Lecour December 19th, 2008 @ 11:49 AM
Freaking strange ! I can't reproce my own bug today, sorry.
If I see it again and can nail it precisely, I'll warn you. Thanks anyway.
-
Pratik December 19th, 2008 @ 01:50 PM
- State changed from new to invalid
Will reopen once we have a test case.
-
Jérémy Lecour December 30th, 2008 @ 11:01 PM
Hey,
I can see it again ! Like I said, on my local (OS X 10.5.6) it's always localized in english, but on my production/staging server (Debian stable up-to-date), it's always in french.
Here is the code involved : http://gist.github.com/41793
I've check for differences in the "locale" command in the shell,
Mac OS X: $ locale LANG="fr_FR.UTF-8" LC_COLLATE="fr_FR.UTF-8" LC_CTYPE="fr_FR.UTF-8" LC_MESSAGES="fr_FR.UTF-8" LC_MONETARY="fr_FR.UTF-8" LC_NUMERIC="fr_FR.UTF-8" LC_TIME="fr_FR.UTF-8" LC_ALL=
Debian: $ locale LANG=fr_FR.UTF-8@euro LC_CTYPE="fr_FR.UTF-8@euro" LC_NUMERIC="fr_FR.UTF-8@euro" LC_TIME="fr_FR.UTF-8@euro" LC_COLLATE="fr_FR.UTF-8@euro" LC_MONETARY="fr_FR.UTF-8@euro" LC_MESSAGES="fr_FR.UTF-8@euro" LC_PAPER="fr_FR.UTF-8@euro" LC_NAME="fr_FR.UTF-8@euro" LC_ADDRESS="fr_FR.UTF-8@euro" LC_TELEPHONE="fr_FR.UTF-8@euro" LC_MEASUREMENT="fr_FR.UTF-8@euro" LC_IDENTIFICATION="fr_FR.UTF-8@euro" LC_ALL=
I suspect this not to be related to rails, but to my environment, although I don't where to look at !
Thanks for any clue.
-
Jérémy Lecour December 30th, 2008 @ 11:12 PM
On the production server, inside the console, it's in english (as it should, and not in french as it is in the real app)
$ script/console staging Loading staging environment (Rails 2.2.2) >> I18n.locale => :fr >> Time.now => Wed Dec 31 00:10:17 +0100 2008 >> Time.now.to_s(:rfc822) => "Wed, 31 Dec 2008 00:10:28 +0100" >>
-
Yaroslav Markin January 1st, 2009 @ 07:15 PM
Can't reproduce:
Loading development environment (Rails 2.3.0) >> I18n.locale => :ru >> Time.now => Thu Jan 01 22:14:11 +0300 2009 >> Time.now.to_s(:rfc822) => "Thu, 01 Jan 2009 22:14:21 +0200" >> I18n.l Time.now => "Чт, 01 янв. 2009, 22:15:17 +0200"
AFAIK Time#to_s should not take I18n into account at all -- you can localize time using I18n.l, but to_s is not overloaded.
-
Yaroslav Markin January 1st, 2009 @ 07:16 PM
You may have some kind of pre-I18n localization plugin/gem installed that overrides Time#to_s
-
Jérémy Lecour January 2nd, 2009 @ 11:40 PM
Hello Yaroslav
Thanks for your help
I'm digging and have not found anything in installed plugins or gem.
I've noticed that in my views :
<% Date.today.strftime("%A") + " - " + Time.now.strftime("%A") %>
turns into
Saturday - samedi
I guess that the Date object is correctly handled (not localized) but the Time is not.
In irb, script/console, or straight ruby in the command line, the Time object is not localized.
I also tested this in another Rails app, running 2.1.1 (same server) and both Date and Time a strftime-ed correctly (ie not localized)
I continue to dig and try to look for the culprit, but if you have any idea with the details I gave you, you're welcome.
Thanks again for what you do
-
Jérémy Lecour January 3rd, 2009 @ 01:27 AM
I've created a brand new app, with Rails 2.2.2 and a basic scaffold just to be able to call a view with some debug code in it.
Everything worked as expected. So I'vetried to move in piece by piece some stuff from my weird app : plugins (1 by 1), initializers, locales, libs, …
Then I remembered that I've seen something strange in Rails about the rfc822 method :
http://github.com/rails/rails/tr... (lines 145 -> 152
def to_s(format = :default) return utc.to_s(format) if format == :db if formatter = ::Time::DATE_FORMATS[format] formatter.respond_to?(:call) ? formatter.call(self).to_s : strftime(formatter) else "#{time.strftime("%Y-%m-%d %H:%M:%S")} #{formatted_offset(false, 'UTC')}" # mimicking Ruby 1.9 Time#to_s format end end
I can see that it checks if the formatter respond_to? :call and if not it uses a basic strftime.
In my new app whre it's working great, I've got this :
I18n.locale : fr I18n.default_locale : fr Date.today.strftime("%A") : Saturday Time.now.strftime("%A") : Saturday Time.now.rfc822 : Sat, 03 Jan 2009 02:13:06 +0100 Time.now.strftime("%a, %d %b %Y %T %z") : Sat, 03 Jan 2009 02:13:06 +0100 I18n.l(Time.now, :format => "%a, %d %b %Y %T %z") : Sam, 03 Jan 2009 02:13:06 +0100
It shows that if I try to localize a Time with a strftime format it's indeed localized.
So I think that maybe it's going through a localized strftime instead of the normal call.
By the way I dont really understand what "formatter.call(self).to_s" does. If it's calling a method named after the formatter if it exists, with self as paramater, it means that it tries to call a rfc822() method. Anyway, I don't get it !
-
Bart Zonneveld June 3rd, 2009 @ 09:38 AM
According to my findings, the localized_dates plugin causes Time.to_s(:rfc822) to be formatted. I'll file a bug report to the maintainers.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>