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!

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)

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>

try this:

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

Regards,
Istvan

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.

Hi try this this will work for u

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

Thanks
Bava

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

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,

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.

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,

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 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,