Displaying a date 'properly'

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!

On Oct 22, 6:01 pm, RubyonRails_newbie [email protected]
wrote:

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

Does anyone know how to implement this?

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.

so, if I put:

def format_date(a_date)

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

end in one of my helpers, what do I need to include int he rhtml page?

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.

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:

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

try this:

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

Regards,
Istvan
On Oct 22, 6:47 pm, RubyonRails_newbie [email protected]

Hi try this this will work for u

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

Thanks
Bava

On Fri, Oct 23, 2009 at 2:06 AM, Robert W. <

Robb Shecter wrote:

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.

Personally, I like the pattern of having separate formatter classes, but
using view helpers isn’t too bad. For example the Cocoa framework
provides NSDateFormatter and NSNumberFormatter. Java also has the
SimpleDateFormat class for this purpose. And, responsibility for I18n
can be delegated to the formatter classes as well.

I like this pattern because the view layer should be responsible for
formatting values for display. Since Date and Time are model objects
they really should not be responsible for formatting their own data.

But, I realize that opinions vary.

Robert W. wrote:
[…]

Personally, I like the pattern of having separate formatter classes, but
using view helpers isn’t too bad. For example the Cocoa framework
provides NSDateFormatter and NSNumberFormatter. Java also has the
SimpleDateFormat class for this purpose. And, responsibility for I18n
can be delegated to the formatter classes as well.

I like this pattern because the view layer should be responsible for
formatting values for display. Since Date and Time are model objects
they really should not be responsible for formatting their own data.

I think I’m going to take issue with this statement. It seems to me
that model objects should know how to format themselves as strings –
after all, that’s part of the class’ interface to its clients.
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.

But, I realize that opinions vary.

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

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Robert W. 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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

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).

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.

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.

Robert W. 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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Robert W. 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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Marnen Laibow-Koser wrote:

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…

It’s often very difficult to stress a point in text conversations
without being misunderstood or giving the wrong impression.

Robert W. wrote:
[…]

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

It’s often very difficult to stress a point in text conversations
without being misunderstood or giving the wrong impression.

Quite so. And I never did get an answer on the point that I found most
interesting – that you seemed to be suggesting that it was feasible to
reuse Formatters for different model classes. Is that correct? Do you
find this feasible? It sounds nice in theory, but it seems to me that a
Formatter would in practice be pretty closely coupled to the model it’s
formatting. Am I wrong?

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs