Displaying a date 'properly'....

rubyonrails-talk
1

Hello everyone,

I'm trying to work out how to display a date correctly in Ruby on Rails.

At the moment i have a profile page, which when you add it on the site, the data to select is in day, month, year EG 01/10/1988

However. When this is saved to the database it looks like: 1988-10-01. Likewise on the site a user will eventually see. If they originally enter it as: 01/10/1988, why does it display backwards?

And, is there a solution to this to allow it to be stored as dd/mm/ yyyy?

Many thanks in advance!

2

However. When this is saved to the database it looks like: 1988-10-01. Likewise on the site a user will eventually see. If they originally enter it as: 01/10/1988, why does it display backwards?

And, is there a solution to this to allow it to be stored as dd/mm/ yyyy?

How the database stores the date isn't really any of your business - chances are that it's not stored as a string at all. What you're seeing is probably just the Date classes default to_s method (which again bears little relationship to how instances of Date store their value) When you get a date out of the database it's up to you to format it the way you want it before display (eg use strftime)/

Fred

3

Does anyone know how to implement this?

4

I put something like this in one of my helpers:

  def format_date(a_date)      a_date.strftime("%B #{a_date.day}, %Y")   end

Should give you a starting point.

5

so, if I put:

def format_date(a_date)

6

so, if I put:

def format_date(a_date)... ...in one of my helpers, what do I need to include in the rhtml page?

You could use it like this:

<p>   Profile was created at <%= format_date(profile.created_at) %> </p>

7

try this:

http://l1xl1x.blogspot.com/2009/10/custom-date-and-time-format-in-rails.html

Regards, Istvan

8

Excellent - sorted. Thanks Robb.

I've amended it slightly, to have it as dd month year, but it's looking good now. Thanks for your help dude!

I'm new to rails - and havent covered this so appreciate the help.

9

Hi try this this will work for u

european_date = ‘%d/%m/%Y’ @date = a_date.strftime(european_date)

Thanks Bava

10

Marnen Laibow-Koser wrote:

Formatter classes may be useful in a language like Java, where you can't reopen Date to add new formats, but at least for simple cases, I fail to see how they're anything but a design smell in Ruby.

I would agree, except for the fact that Obj-C has the ability to extend existing classes without subclassing just as Ruby does. This is done through the use of categories. Yet Cocoa does use formatter classes for numbers and dates. So the closed class argument doesn't hold water in this case. What does make a difference is that Cocoa is a desktop application framework with a more extensive use of the MVC pattern than does Rails.

Yes. And it may be that your approach has some benefits that I haven't thought of... Best,

There is a very fine line between model and view responsibility in the case of numbers and dates. I agree that it's good for model object to know how to present themselves to the view, but in the case of numbers and dates there can be some benefit in factoring out that responsibility to view helper classes (i.e. NSNumberFormatter & NSDateFormatter).

11

Robert Walker wrote:

Marnen Laibow-Koser wrote:

Formatter classes may be useful in a language like Java, where you can't reopen Date to add new formats, but at least for simple cases, I fail to see how they're anything but a design smell in Ruby.

I would agree, except for the fact that Obj-C has the ability to extend existing classes without subclassing just as Ruby does. This is done through the use of categories. Yet Cocoa does use formatter classes for numbers and dates. So the closed class argument doesn't hold water in this case.

Or Cocoa is poorly designed in this regard. (And Obj-C is such a weird language that it wouldn't entirely surprise me if there was in fact a language reason for this decision.)

What does make a difference is that Cocoa is a desktop application framework

Perhaps. The complexity of the formatting might also make a difference -- I wouldn't want to put a whole Rails partial into a to_s in most cases!

with a more extensive use of the MVC pattern than does Rails.

My impression from the little bit I've played with Cocoa is that it has a very *different* way of using the MVC pattern than does Rails.

Yes. And it may be that your approach has some benefits that I haven't thought of... Best,

There is a very fine line between model and view responsibility in the case of numbers and dates. I agree that it's good for model object to know how to present themselves to the view, but in the case of numbers and dates there can be some benefit in factoring out that responsibility to view helper classes (i.e. NSNumberFormatter & NSDateFormatter).

What is that benefit? Making it easier to adapt to the user's preferences?

Best,

12

Marnen Laibow-Koser wrote:

Or Cocoa is poorly designed in this regard. (And Obj-C is such a weird language that it wouldn't entirely surprise me if there was in fact a language reason for this decision.)

So you're saying here that Cocoa MUST be poorly designed, and Obc-C is weird, because you don't understand it? How about let's leave the code bigotry out of the discussion.

What does make a difference is that Cocoa is a desktop application framework

Perhaps. The complexity of the formatting might also make a difference -- I wouldn't want to put a whole Rails partial into a to_s in most cases!

with a more extensive use of the MVC pattern than does Rails.

My impression from the little bit I've played with Cocoa is that it has a very *different* way of using the MVC pattern than does Rails.

Yes, I agree. Cocoa implements the "original" MVC design pattern (with some variations). MVC actually does predate the web itself after all.

Yes. And it may be that your approach has some benefits that I haven't thought of... Best,

There is a very fine line between model and view responsibility in the case of numbers and dates. I agree that it's good for model object to know how to present themselves to the view, but in the case of numbers and dates there can be some benefit in factoring out that responsibility to view helper classes (i.e. NSNumberFormatter & NSDateFormatter).

What is that benefit? Making it easier to adapt to the user's preferences?

If you consider separation of responsibility a benefit, then the formatter pattern has the same benefit as the MVC design pattern. Formatters can be attached to other view objects, such as text fields or any other view object responsible for displaying, validating and interpreting data. This attachment can then be implemented and managed completely within the view layer isolating the responsibility from the model and controller layers.

13

Robert Walker wrote:

Marnen Laibow-Koser wrote:

Or Cocoa is poorly designed in this regard. (And Obj-C is such a weird language that it wouldn't entirely surprise me if there was in fact a language reason for this decision.)

So you're saying here that Cocoa MUST be poorly designed, and Obc-C is weird, because you don't understand it?

No, that's absolutely *not* what I meant; sorry if I was unclear. I meant this: * You seemed to be saying that we should use this pattern because Cocoa does. My respose was that yes, that's possible, but it's also possible that Cocoa made a mistake. I make no judgement on which is the case; I merely wanted to point out the other possibility. As far as Obj-C being weird, well...I think it is. That doesn't mean I dislike it; in fact, I think it's kind of neat. But a C-Smalltalk hybrid is like garlic-flavored ice cream: even if you like the way it tastes, it's still conceptually odd. :slight_smile:

How about let's leave the code bigotry out of the discussion.

Happy to. No code bigotry was meant on my part at all.

What does make a difference is that Cocoa is a desktop application framework

Perhaps. The complexity of the formatting might also make a difference -- I wouldn't want to put a whole Rails partial into a to_s in most cases!

with a more extensive use of the MVC pattern than does Rails.

My impression from the little bit I've played with Cocoa is that it has a very *different* way of using the MVC pattern than does Rails.

Yes, I agree. Cocoa implements the "original" MVC design pattern (with some variations).

Yes, that was my impression. Rails' MVC is a bit idiosyncratic.

MVC actually does predate the web itself after all.

I know. And Reenskaug-style MVC is probably not that well suited to the Web without some modifications (I've just been reading a bunch of stuff on Ward's Wiki about this, in fact).

Yes. And it may be that your approach has some benefits that I haven't thought of... Best,

There is a very fine line between model and view responsibility in the case of numbers and dates. I agree that it's good for model object to know how to present themselves to the view, but in the case of numbers and dates there can be some benefit in factoring out that responsibility to view helper classes (i.e. NSNumberFormatter & NSDateFormatter).

What is that benefit? Making it easier to adapt to the user's preferences?

If you consider separation of responsibility a benefit, then the formatter pattern has the same benefit as the MVC design pattern. Formatters can be attached to other view objects, such as text fields or any other view object responsible for displaying, validating and interpreting data. This attachment can then be implemented and managed completely within the view layer isolating the responsibility from the model and controller layers.

Perhaps. I'll have to think about this some more. This looks like about the same thing as the Presenter pattern that Jay Fields has written about, and frankly, I'm suspicious of it. It looks like needless complexity and/or too much logic in the view layer.

Or are you saying that one could potentially use the same Formatter/Presenter for two completely different underlying models? That could certainly be an advantage of introducing the extra layer.

Best,

14

Marnen Laibow-Koser wrote:

* You seemed to be saying that we should use this pattern because Cocoa does. My respose was that yes, that's possible, but it's also possible that Cocoa made a mistake. I make no judgement on which is the case; I merely wanted to point out the other possibility. As far as Obj-C being weird, well...I think it is. That doesn't mean I dislike it; in fact, I think it's kind of neat. But a C-Smalltalk hybrid is like garlic-flavored ice cream: even if you like the way it tastes, it's still conceptually odd. :slight_smile:

Actually, I'm not saying that at all. This all got started by my saying that I like this pattern that I've seen used in other places. If you look back at earlier posts, I also said that view helpers are a fine substitute in the context of Rails. I tend to draw on experience from across all the languages and frameworks I've used. I think they all have something to teach us, whether we necessarily like everything about them or not.

In regards to the C-Smalltalk hybrid nature of Obj-C: I believe that grew out of both a need and a want. The designers of the language were obviously fans of Smalltalk (or at least certain aspects of it), but also had a need to be directly compatible with the huge amount of C code that operating systems and services were written in. Not every language can be purely "green-field" like Ruby, or even Java.

Even today there is still a huge amount of pure C code running most modern operating systems. When you are writing applications running directly on top of that code, a hybrid like ObJ-C is a great solution. It provides a clean object-oriented model, that can still be intermixed with all that legacy C code.

P.S. I sorry if my prior post sounded harsh. I was simply trying to make a point. I know that you're a great developer, I follow your posts and agree with the vast majority of your replies. I just think we need to be careful of falling into the "elitists" trap thinking that "our" way is the "only" way. I love Ruby and Rails, but that doesn't mean that I'm going to forget the lessons I've learned from other solutions, or disregard them because they're different.

15

Robert Walker wrote:

Marnen Laibow-Koser wrote:

* You seemed to be saying that we should use this pattern because Cocoa does. My respose was that yes, that's possible, but it's also possible that Cocoa made a mistake. I make no judgement on which is the case; I merely wanted to point out the other possibility. As far as Obj-C being weird, well...I think it is. That doesn't mean I dislike it; in fact, I think it's kind of neat. But a C-Smalltalk hybrid is like garlic-flavored ice cream: even if you like the way it tastes, it's still conceptually odd. :slight_smile:

Actually, I'm not saying that at all. This all got started by my saying that I like this pattern that I've seen used in other places. If you look back at earlier posts, I also said that view helpers are a fine substitute in the context of Rails. I tend to draw on experience from across all the languages and frameworks I've used. I think they all have something to teach us, whether we necessarily like everything about them or not.

In regards to the C-Smalltalk hybrid nature of Obj-C: I believe that grew out of both a need and a want. The designers of the language were obviously fans of Smalltalk (or at least certain aspects of it), but also had a need to be directly compatible with the huge amount of C code that operating systems and services were written in. Not every language can be purely "green-field" like Ruby, or even Java.

I never said it could.

Even today there is still a huge amount of pure C code running most modern operating systems.

Of course.

When you are writing applications running directly on top of that code, a hybrid like ObJ-C is a great solution. It provides a clean object-oriented model, that can still be intermixed with all that legacy C code.

I never said it wasn't a good solution for the problem it was meant to solve. I don't know where you're getting the idea that I did.

P.S. I sorry if my prior post sounded harsh. I was simply trying to make a point. I know that you're a great developer, I follow your posts and agree with the vast majority of your replies. I just think we need to be careful of falling into the "elitists" trap thinking that "our" way is the "only" way.

I agree.

I love Ruby and Rails, but that doesn't mean that I'm going to forget the lessons I've learned from other solutions, or disregard them because they're different.

Nor I. And yet that's exactly what it appeared that you were doing with Cocoa...

Best,