On Sat, May 3, 2014 at 12:56 AM, Yukihiro Matsumoto <matz / ruby.or.jp> wrote:

> In message "Re: Who the f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?"
>     on Fri, 2 May 2014 22:33:21 -0500, Felipe Contreras <felipe.contreras / gmail.com> writes:
>
> |So, if both "%s" "%z" are "undefined" should Ruby ignore them? No, if
> |they have an understood meaning outside of POSIX, mainly GNU libc, it
> |makes sense for Ruby to support them, specially when it doesn't cause
> |any conflict to do that, and they are useful.
> |
> |So how about "%s %z"? Well, it does work correctly in GNU libc (see
> |program below), so if we follow GNU libc for "%s", and for "%z", why
> |not for "%s %z"?
>
> The behavior of strptime(3) is full of ad-hoc matching, and often
> misbehave.  In the past, Tadayoshi hesitated to support that ugly
> behavior and we took long time to persuade him (to support most common
> cases).  This is only my guess, but he might feel this could be a
> start of bunch of requests for supporting every corner bit of
> strptime(3) behavior of the specific implementation (namely glibc).

Ah, the good old slippery slope fallacy[1]. How about we concentrate
on the issue at hand and not worry about hypothetical futures that
won't happen?

Moreover, if you accept that we follow glibc for "%s" and "%z", why
would you argue that it's wrong to follow what glibc does for "%s %z"?

> Remember, in the C specification, struct tm does not have a member to
> preserve timezone (although glibc has).  Your expectation to Time and
> DateTime can only meet on some but not all platforms.

This doesn't follow. Neither Time nor DateTime use the system's
strptime(3), so it's up to us to determine the behavior we want of
these which would work on all systems.

And since you already accepted "%s" is not POSIX, it follows that the
expectation of strptime("%s") might not be met either on some
platforms, yet it's part of both Time and DateTime already.

And why are you ignoring my other arguments?

1) DateTime.strftime with "%s %z" is *already* using the tz instead of UTC
2) Time.strptime with "%s %z" is *already* using the tz (and Time.strftime)

Why would you create this inconsistency? Even if you ignore the
behavior of glibc, Ruby MRI is *already* using the timezone correctly
for "%s %z" in several places. I would really like an answer to that.

  DateTime.parse("1970-01-01 01:00 +0100").strftime("%s %z")
  => "0 +0100"

> Considering that, compatibility to other implementations (on glibc) is
> not useful to persuade him, but showing importance to support "%s %z"
> universally in the real-world use-case might be.

Why are we talking about persuading him? If we, the project, agree
that this is the way to go, why would the opinion of a single person
hold hostage the change we all agree is right?

And I'm still waiting for a single reason why the patch should not be
applied. What problem could it possibly create to anyone?

Cheers.

[1] http://en.wikipedia.org/wiki/Slippery_slope

-- 
Felipe Contreras