https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112020-02-17T16:43:23ZRuby Issue Tracking SystemRuby master - Feature #16637: Time#to_s and Date#to_s accept strftime format stringhttps://bugs.ruby-lang.org/issues/16637?journal_id=842882020-02-17T16:43:23Zttilberg (Tim Tilberg)
<ul></ul><p><a href="https://www.reddit.com/r/ruby/comments/f4pcn5/dateformatter_gem_date_formatter_by_example/fhxkn8f/" class="external">Gerald Bauer pointed out</a> that this concept already exists in Rails' ActiveSupport: <a href="https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/time/conversions.rb" class="external">https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/time/conversions.rb</a></p>
<p>Is this a case where we might consider integrating this idea from Rails? I feel like it's very much in the spirit of core Ruby, with attention to developer happiness. It always surprises me how much I have to look up when I'm printing date/time as strings.</p> Ruby master - Feature #16637: Time#to_s and Date#to_s accept strftime format stringhttps://bugs.ruby-lang.org/issues/16637?journal_id=842892020-02-17T16:54:23Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><blockquote>
<p>While terms like strftime and strptime are ubiqutous through the history of computer science,<br>
I feel that the terms are very dense.</p>
</blockquote>
<p>Agreed. I can't remember them offhand either, I just copy/paste from my local knowledgebase. ;-)<br>
(Though I do happen to have a bad memory at any rate.)</p>
<p>To the proposal, though:</p>
<pre><code>Time.now.to_s('%Y-%m-%d')
</code></pre>
<p>I am not sure if this is a good suggestion though, largely because .to_s already having a<br>
distinct meaning, e. g. "to string" (or to a string representation).</p>
<p>People also typically associate .to_s, if there is an argument, with something like this:</p>
<pre><code>37.to_s(2).rjust(8, "0") # => "00100101"
</code></pre>
<p>So I think this should be considered as well, since the trade-off here is that .to_s<br>
would become a bit more complex.</p>
<blockquote>
<p>(As an aside for discussion, I feel this way about formatting things like Floats<br>
and other numbers also. That API is equally confusing, and a holdover from history<br>
in comp-sci.)</p>
</blockquote>
<p>I do not disagree with you here on the premise - I think it may be inspired a lot by<br>
C, and C may have been inspired by ... I don't know. Often people just typing less<br>
on UNIX I guess (e. g. /usr versus /users or /users and so forth, but you may wonder<br>
why it is called /usr/include/ rather than /usr/inc/ ... a lot of these things are<br>
not very logical or consistent. See also the explanation of how the /usr/sbin/<br>
versus /sbin/ distinction came about, and the FHS not really making a whole lot<br>
of sense ... but I digress.)</p>
<p>I am just not entirely sure if .to_s should be modified.</p>
<p>I have no real strong preference either way though, just the trade-offs have to be<br>
considered.</p>
<blockquote>
<p>but how do people feel about allowing a format string as an argument for #to_s?</p>
</blockquote>
<p>Ultimately you have to convince matz. :)</p>
<p>I think it may be worth to consider whether it would/could be another method,<br>
other than .to_s, IF is to be considered that .to_s should not be changed. Then<br>
there could simply be an alias that may be easier to remember. Note that even<br>
in the .to_s example, people may not always remember the various format<br>
parameters without having to look them up. Perhaps it may be time for something<br>
simpler to remember altogether ... but I have no good suggestion for this either.</p>
<p>I'll just keep on copy/pasting from my local knowledgebase. :D</p>
<blockquote>
<p>[...] this concept already exists in Rails' ActiveSupport:<br>
<a href="https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/time/conversions.rb" class="external">https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/time/conversions.rb</a></p>
</blockquote>
<p>The active* ecosystem is very large, though. I am not sure if applying it as<br>
primary means of reasoning should be the primary explanation. Some time ago I<br>
suggested some alias to be added to core ruby, which matz approved; at a later<br>
time I found out that rails did have the same alias (I did not know that before).</p>
<p>Again, though, it is not me saying yes or no to that - just wanting to keep<br>
the discussion more open. :)</p>
<blockquote>
<p>Is this a case where we might consider integrating this idea from Rails?</p>
</blockquote>
<p>I suppose if it makes sense from a core ruby perspective, e. g. may benefit<br>
the ruby ecosystem. (Ruby is also used in non-rails areas.)</p>
<blockquote>
<p>I feel like it's very much in the spirit of core Ruby, with attention<br>
to developer happiness.</p>
</blockquote>
<p>Well, this is a bit difficult because you can make a language very complex,<br>
and keep on thinking that it makes developers happy. So we end up with<br>
C++. :D</p>
<blockquote>
<p>It always surprises me how much I have to look up when I'm printing date/time<br>
as strings.</p>
</blockquote>
<p>Yes, this part I agree with. I am just not automatically sure that the proposal<br>
of changing .to_s should be the one that addresses this, or the issue. (On a<br>
side note, for a similar reason I did not like the old global variables inspired<br>
from perl; I always have to look them up and can never remember them. I do not<br>
use them much at all these days though.)</p> Ruby master - Feature #16637: Time#to_s and Date#to_s accept strftime format stringhttps://bugs.ruby-lang.org/issues/16637?journal_id=842902020-02-17T19:56:52Zsawa (Tsuyoshi Sawada)
<ul></ul><p>Since the receiver is a <code>Time</code> object or <code>Time</code>, at least the <code>time</code>-part in <code>strftime</code> and <code>strptime</code> is redundant. That is for sure. Perhaps aliases like <code>Time#strf</code>, <code>Time.strp</code> may make sense.</p> Ruby master - Feature #16637: Time#to_s and Date#to_s accept strftime format stringhttps://bugs.ruby-lang.org/issues/16637?journal_id=842912020-02-17T21:46:19Zttilberg (Tim Tilberg)
<ul></ul><p>shevegen (Robert A. Heiler) wrote in <a href="#note-2">#note-2</a>:</p>
<blockquote>
<p>I am not sure if this is a good suggestion though, largely because .to_s already having a<br>
distinct meaning, e. g. "to string" (or to a string representation).</p>
<p>People also typically associate .to_s, if there is an argument, with something like this:</p>
<pre><code>37.to_s(2).rjust(8, "0") # => "00100101"
</code></pre>
</blockquote>
<p>I feel that this directly supports the proposal in that when you call <code>#to_s</code> on a <code>Time</code> or <code>Date</code> object, you are casting this object to a string representation, which could be formatted whichever way. The fact that the current <code>#to_s</code> already includes a default <code>strftime</code> format further suggests that this feels like the right place. Finally, I feel that casting an integer to string, and being able to specify that it should be represented as binary further supports this cause.</p>
<p>I should note, I have no desire to introduce something that doesn't slot in naturally, but I think since this method previously did not take any args, it <em>should</em> be able to change without breaking anything, right? If there are edge cases where this may not be true, than I do not want to support <code>#to_s(format)</code> and instead would prefer an alternate name. However <code>#format</code> is already taken and marked private.</p>
<p>sawa (Tsuyoshi Sawada) wrote in <a href="#note-3">#note-3</a>:</p>
<blockquote>
<p>at least the time-part in strftime and strptime is redundant. That is for sure. Perhaps aliases like Time#strf, Time.strp may make sense.</p>
</blockquote>
<p>Oh my. Yes, this seems even more clear that the notion of using <code>strftime</code> (and <code>strf</code>) is unnatural (with exception to the fact that languages have used these terms forever. However, this is Ruby! We are people, not machines!). I find <code>#strf</code> equally unintuitive.</p>
<p>Personal anecdote: Whenever I see <code>strftime</code> I always think "string from time" first, and <code>strptime</code> as "string print time".</p>
<p>Thank you for your comments so far, folks.</p>