Rails - Oct 2009 - 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
<craigwest...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
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
> Many thanks in advance!

Does anyone know how to implement this?

On 22 Oct, 18:27, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Oct 22, 6:01 pm, RubyonRails_newbie
<craigwest...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> 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
>
>
>
> > Many thanks in advance!

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?
On 22 Oct, 18:57, Robb
<robb.shec...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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.

> 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
On Oct 22, 6:47 pm, RubyonRails_newbie
<craigwest...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
wrote:
> Does anyone know how to implement this?
>
> On 22 Oct, 18:27, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> > On Oct 22, 6:01 pm, RubyonRails_newbie
<craigwest...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > 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
>
> > > Many thanks in advance!

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.

On 22 Oct, 19:41, Robb
<robb.shec...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > 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>

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.
-- 
Posted via http://www.ruby-forum.com/.

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 Walker <
rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
>
> 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.
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Robert Walker 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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).
-- 
Posted via http://www.ruby-forum.com/.

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
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

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.
-- 
Posted via http://www.ruby-forum.com/.

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. :)
> 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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. :)
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.
-- 
Posted via http://www.ruby-forum.com/.

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. :)
> 
> 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

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.
-- 
Posted via http://www.ruby-forum.com/.

Robert Walker 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.