Rails Ruby on Rails

Comments and changes to this ticket

• You flagged this item as spam.
  

  Damien MATHIEU January 27th, 2010 @ 02:59 PM

  Could you submit a patch ?

• You flagged this item as spam.
  

  Yaroslav Markin February 13th, 2010 @ 05:29 PM

  • Assigned user set to “Sven Fuchs”
• 

  Ryan Bigg May 25th, 2010 @ 10:59 AM

  • Tag changed from “date, formatting, i18n” to “bugmash, date, formatting, i18n”
  • State changed from “new” to “open”

• You flagged this item as spam.
  

  masone July 17th, 2010 @ 02:27 PM

  • Importance changed from “” to “Low”

  I worked a bit on this problem and attached a patch. Two tests are not passing because I wanted to hear your opinion on the desired behavior. It does only apply to master and would need to be ported to 2-3stable manually.

  I added I18n to Time, Date, Datetime and TimeWithZone. There is a test for each of the following cases:
  to_s with default format to_s with undefined format to_s with custom format to_s with a lambda as custom format

  Things I think are worth pointing out:
  The DATE_FORMATS now only includes System-like formats, that don't need to be localized (eg. :db, :number, :rfc822) New formats can now be added without extending DATE_FORMATS. The symbol passed to to_s only needs a matching translation. If the user passes a lambda as custom format, he has to care about I18n by himself. The long_ordinal format is thus not localized (the method ordinalize isn't localized yet either). This problem does not apply to all languages anyway. * Some formats defined in DATE_FORMATS did not match the formats defined in the locales/en.yml, so I changed some default values in the locale file to satisfy the tests.

  And here are the points that are still open and I need your help:
  1) /test/core_ext/time_ext_test.rb:496:in test_to_s' fails. I'm not sure if it's just a problem with the assertion or if I messed up something with the timezones.<br/> 2) test/core_ext/date_time_ext_test.rb:14:intest_to_s' fails because the new default value from the locales file does not match the default value previously defined in DATE_FORMATS. I'm not sure what consequences there could be if I just changed the default value.

  Please review this patch carefully. It is my first one and I initially felt like it was no big deal but I ended up changing some essential behavior. Plus I'm not really experienced with time zones.

  Thanks for your feedback.

  • 3798-dateto_s-should-use-i18n-masone.diff 16 KB

• You flagged this item as spam.
  

  masone July 17th, 2010 @ 02:32 PM

  I worked a bit on this problem and attached a patch. Two tests are not passing because I wanted to hear your opinion on the desired behavior. It does only apply to master and would need to be ported to 2-3stable manually.

  I added I18n to Time, Date, Datetime and TimeWithZone. There is a test for each of the following cases:

  • to_s with default format
  • to_s with undefined format
  • to_s with custom format
  • to_s with a lambda as custom format

  Things I think are worth pointing out:

  • The DATE_FORMATS now only includes System-like formats, that don't need to be localized (eg. :db, :number, :rfc822)
  • New formats can now be added without extending DATE_FORMATS. The symbol passed to to_s only needs a matching translation.
  • If the user passes a lambda as custom format, he has to care about I18n by himself.
  • The long_ordinal format is thus not localized (the method ordinalize isn't localized yet either). This problem does not apply to all languages anyway.
  • Some formats defined in DATE_FORMATS did not match the formats defined in the locales/en.yml, so I changed some default values in the locale file to satisfy the tests.

  And here are the points that are still open and I need your help:

  1. /test/core_ext/time_ext_test.rb:496:in test_to_s' fails. I'm not sure if it's just a problem with the assertion or if I messed up something with the timezones.<br/>
  2. test/core_ext/date_time_ext_test.rb:14:in test_to_s' fails because the new default value from the locales file does not match the default value previously defined in DATE_FORMATS. I'm not sure what consequences there could be if I just changed the default value.

  Please review this patch carefully. It is my first one and I initially felt like it was no big deal but I ended up changing some essential behavior. Plus I'm not really experienced with time zones.

  Thanks for your feedback.

  • 3798-dateto_s-should-use-i18n-masone.diff 16 KB

• You flagged this item as spam.
  

  masone September 4th, 2010 @ 09:43 AM

  • Title changed from “Date#to_s should use I18n” to “[PATCH] Date#to_s should use I18n”
  • Tag changed from “bugmash, date, formatting, i18n” to “bugmash, date, formatting, i18n, patch”
• 

  Santiago Pastorino February 2nd, 2011 @ 04:48 PM

  This issue has been automatically marked as stale because it has not been commented on for at least three months.

  The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

  Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

• 

  Santiago Pastorino February 2nd, 2011 @ 04:48 PM

  • State changed from “open” to “stale”