[#97086] [Ruby master Bug#16612] Enumerator::ArithmeticSequence#last with float range produces incorrect value — muraken@...
Issue #16612 has been updated by mrkn (Kenta Murata).
4 messages
2020/02/07
[#97095] [PATCH] Modify shebang of libexec/y2racc and libexec/racc2y. — Wang Mingyu <wangmy@...>
change /usr/local/bin/ruby to /usr/bin/env ruby.
3 messages
2020/02/08
[#97307] [Ruby master Feature#16663] Add block or filtered forms of Kernel#caller to allow early bail-out — headius@...
Issue #16663 has been reported by headius (Charles Nutter).
29 messages
2020/02/28
[ruby-core:97181] [Ruby master Feature#16637] Time#to_s and Date#to_s accept strftime format string
From:
shevegen@...
Date:
2020-02-17 16:54:24 UTC
List:
ruby-core #97181
Issue #16637 has been updated by shevegen (Robert A. Heiler).
> While terms like strftime and strptime are ubiqutous through the history of computer science,
> I feel that the terms are very dense.
Agreed. I can't remember them offhand either, I just copy/paste from my local knowledgebase. ;-)
(Though I do happen to have a bad memory at any rate.)
To the proposal, though:
Time.now.to_s('%Y-%m-%d')
I am not sure if this is a good suggestion though, largely because .to_s already having a
distinct meaning, e. g. "to string" (or to a string representation).
People also typically associate .to_s, if there is an argument, with something like this:
37.to_s(2).rjust(8, "0") # => "00100101"
So I think this should be considered as well, since the trade-off here is that .to_s
would become a bit more complex.
> (As an aside for discussion, I feel this way about formatting things like Floats
> and other numbers also. That API is equally confusing, and a holdover from history
> in comp-sci.)
I do not disagree with you here on the premise - I think it may be inspired a lot by
C, and C may have been inspired by ... I don't know. Often people just typing less
on UNIX I guess (e. g. /usr versus /users or /users and so forth, but you may wonder
why it is called /usr/include/ rather than /usr/inc/ ... a lot of these things are
not very logical or consistent. See also the explanation of how the /usr/sbin/
versus /sbin/ distinction came about, and the FHS not really making a whole lot
of sense ... but I digress.)
I am just not entirely sure if .to_s should be modified.
I have no real strong preference either way though, just the trade-offs have to be
considered.
> but how do people feel about allowing a format string as an argument for #to_s?
Ultimately you have to convince matz. :)
I think it may be worth to consider whether it would/could be another method,
other than .to_s, IF is to be considered that .to_s should not be changed. Then
there could simply be an alias that may be easier to remember. Note that even
in the .to_s example, people may not always remember the various format
parameters without having to look them up. Perhaps it may be time for something
simpler to remember altogether ... but I have no good suggestion for this either.
I'll just keep on copy/pasting from my local knowledgebase. :D
> [...] this concept already exists in Rails' ActiveSupport:
> https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/time/conversions.rb
The active* ecosystem is very large, though. I am not sure if applying it as
primary means of reasoning should be the primary explanation. Some time ago I
suggested some alias to be added to core ruby, which matz approved; at a later
time I found out that rails did have the same alias (I did not know that before).
Again, though, it is not me saying yes or no to that - just wanting to keep
the discussion more open. :)
> Is this a case where we might consider integrating this idea from Rails?
I suppose if it makes sense from a core ruby perspective, e. g. may benefit
the ruby ecosystem. (Ruby is also used in non-rails areas.)
> I feel like it's very much in the spirit of core Ruby, with attention
> to developer happiness.
Well, this is a bit difficult because you can make a language very complex,
and keep on thinking that it makes developers happy. So we end up with
C++. :D
> It always surprises me how much I have to look up when I'm printing date/time
> as strings.
Yes, this part I agree with. I am just not automatically sure that the proposal
of changing .to_s should be the one that addresses this, or the issue. (On a
side note, for a similar reason I did not like the old global variables inspired
from perl; I always have to look them up and can never remember them. I do not
use them much at all these days though.)
----------------------------------------
Feature #16637: Time#to_s and Date#to_s accept strftime format string
https://bugs.ruby-lang.org/issues/16637#change-84289
* Author: ttilberg (Tim Tilberg)
* Status: Open
* Priority: Normal
----------------------------------------
While terms like `strftime` and `strptime` are ubiqutous through the history of computer science, I feel that the terms are very dense. If you are not already in-the-know, they are gibberish. If you are in the know, they are still a bit clunky. While discussing ways to improve the Time and Date formatting APIs for humanity, I thought a quick and easy improvement would be removing the need to use the method `#strftime`. `#format` is already reserved as a private method, but how do people feel about allowing a format string as an argument for `#to_s`?
I'm not comfortable writing C, but the relevant code is [here](https://github.com/ruby/ruby/blob/dcb05179a969a024bbd3b7622f67468ddf07638c/time.c#L4097)
It seems like it would be straightforward to use the current strings as default values, but to allow for a format string to be passed in.
```
time_to_s(VALUE time) // add format arg
{
struct time_object *tobj;
GetTimeval(time, tobj);
if (TZMODE_UTC_P(tobj))
return strftimev("%Y-%m-%d %H:%M:%S UTC", time, rb_usascii_encoding()); // format || "%Y-%m-%d %H:%M:%S UTC"
else
return strftimev("%Y-%m-%d %H:%M:%S %z", time, rb_usascii_encoding()); // format || "%Y-%m-%d %H:%M:%S %z"
}
```
This would allow an API that feels a bit more intuitive. You still have to know the formatting symbols, but it creates a much more expressive statement:
```
# The current time, to string. What kind of string? A Y-m-d string.
Time.now.to_s('%Y-%m-%d')
```
(As an aside for discussion, I feel this way about formatting things like Floats and other numbers also. That API is equally confusing, and a holdover from history in comp-sci.)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>