Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

[PATCH] Date#to_s should use I18n

#3798

I think the methods for string conversions, like to_formatted_s, found in ActiveSupport::CoreExtensions::[Date,Time,...]::Conversions, should use the I18n API.

For exemple, when I wish use a formatted date like mydate.to_s, the to_s method should use something like I18n.l(self, :format => format).

So, the configuration this conversions will be more DRY.

For while, I am using this plugin: http://github.com/lucasdecastro/conversions_with_i18n

Reported by Lucas de Castro · January 27th, 2010 @ 02:46 PM

State: stale
Milestone: none
Assigned to: Sven Fuchs Sven Fuchs
Importance: Low

Activity

  1. Damien MATHIEU
    Damien MATHIEU

    Could you submit a patch ?

    January 27th, 2010 @ 02:59 PM

  2. Yaroslav Markin
    Yaroslav Markin
    • Assigned user set to Sven Fuchs

    February 13th, 2010 @ 05:29 PM

  3. Ryan Bigg
    Ryan Bigg
    • Tag changed from date, formatting, i18n to bugmash, date, formatting, i18n
    • State changed from new to open

    May 25th, 2010 @ 10:59 AM

  4. masone
    masone
    • 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.

    July 17th, 2010 @ 02:27 PM

  5. masone
    masone

    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.

    July 17th, 2010 @ 02:32 PM

  6. masone
    masone
    • 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

    September 4th, 2010 @ 09:43 AM

  7. Santiago Pastorino
    Santiago Pastorino

    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.

    February 2nd, 2011 @ 04:48 PM

  8. Santiago Pastorino
    Santiago Pastorino
    • State changed from open to stale

    February 2nd, 2011 @ 04:48 PM