Who the f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?

Ruby
1

Hi,

I’ve spent a lot of time trying to fix Ruby’s bad handling of the “%s
%z” time format that is used in every Git commit. It’s now fixed for
Time and in Rubinius both Time and DateTime without affecting anybody
negatively.

The only one remaining is DateTime, and as you can see in the bug
report[1], the rationale is perfectly sensible, the fix simple, clean,
and unobtrusive.

Yet this guy, Tadayoshi F., closes it immediately without any
reason given. After I complained he gives what is probably a bullshit
reason, it’s hard to know because it’s in Japanese, but the code in
the explanation is most definitely a red herring. This is probably due
to an earlier discussion [2] in which he didn’t explain anything
either.

So my question is: who the f*uck is this guy? And why can he just
reject sensible patches like that?

After a private discussion with somebody heavily involved in Ruby, I
was enlightened to the fact that Ruby development is heavily
influenced by Japanese culture, so every component has a clear
maintainer, and he has the final word, regardless of their bullshit
reasons.

This model is clearly wrong. The most successful projects out there
(e.g. Linux, Git) do not have maintainers making decisions
unilaterally, but rather discussion and consensus are more important
than authority. This ensures that if the maintainer is wrong (we are
all wrong sometimes (some more than others)), the project doesn’t
suffer as a result.

If you must have a maintainer that makes decisions unilaterally,
shouldn’t it be a sensible person able to communicate properly? This
is something Tadayoshi F. is not. Apparently he cannot even speak
English, so what is he doing maintaining a module of such an important
project as Ruby?

I believe this explains a lot about why Ruby has such a problem
gaining and maintaining popularity. Even though the language is
extremely awesome, the implementation cannot advance as it should,
heavily in part due to this Japanese culture.

This forces projects like Rubinius, and RubySL. I’ve talked to people
in those projects who are heavily discontented with the way Ruby MRI
does things; ignoring the larger community out there (who are not
Japanese).

For example, Ruby MRI doesn’t match the RubySpec, and why do the
developers do? Nothing, ignore the RubySpec (at the moment of writing
this I see 25 failures).

If this political and cultural bullshit continues, I’m afraid Ruby
won’t ever be as successful as similar but inferior languages such as
Python, and whatever popularity it gains, it will quickly loose it as
it did in 2008[3]. It will become a lost gem, like so many good
Japanese things, only used in Japan (if at all), and ignored by the
rest of the world.

I hope Ruby becomes a sensible truly international project, adopt
practices of other successful open source projects, and let go of this
NIH bullshit.

[1] Feature #9794: DateTime.strptime() doesn't work correctly for '%s %z' - Ruby master - Ruby Issue Tracking System
[2] Bug #7445: strptime('%s %z') doesn't work - Ruby master - Ruby Issue Tracking System
[3] Home - TIOBE

2

Felipe C. [email protected] wrote:

So my question is: who the f*uck is this guy?

Please relax, Felipe. I don’t know tadf, but I do know your attitude
on git-ML is not appreciated there, either.

If your attitude were better, you may do a better job of convincing
people to accept your changes.

If tadf is wrong, then matz may override his decision. But please be
nice about it, it’s not the end of the world if a bug is not fixed.

3

On 2 May 2014, at 13:22, Felipe C. [email protected]
wrote:

If you must have a maintainer that makes decisions unilaterally,
shouldn’t it be a sensible person able to communicate properly? This
is something Tadayoshi F. is not. Apparently he cannot even speak
English, so what is he doing maintaining a module of such an important
project as Ruby?

I believe this explains a lot about why Ruby has such a problem
gaining and maintaining popularity. Even though the language is
extremely awesome, the implementation cannot advance as it should,
heavily in part due to this Japanese culture.

Rubyists are open and welcoming people able to navigate cultural issues
without resorting to racist rants.

I think you should find a different language.

4

Or Rubyists are unable to understand the frustration that a language
barrier has created on an important module? And thus resort to labeling
it
as a racists rant with remarks about leaving the community instead of
attempting to understand the issue at hand which is that Felipe cannot
get
a straightforward response about why his proposed changes were rejected?

5

Perhaps the response was less than straightforward, but that does not
excuse the lack of tact in addressing it. There are far more civil ways
to
raise a concern than this, remember folks, MINASWAN.

6

Since you do not seem to be able to read Japanese. Let me give you a
quick
summary:

This is the same fix you submitted before.
Stop being a [insert your favourite, it does not make any difference].
Don’t come back again.

Considering the duplicate issues, and your general choice of language
when
discussing the changes you are requesting I am honestly surprised that
you
received any response at all.

I’d also like to see Funaba-san not lower himself to your tone.
(鬱陶しくても、「あんた」や「もう来るな」はちょっと見苦しいです。)

I certainly understand the frustration, but I think everyone in this
community wants to maintain the high level of professionalism and shared
respect that has made Ruby such an amazing community.

To all of the people that have worked so hard to make Ruby the language
it
is today, and to those who continue to improve it, please accept our
sincerest gratitude.

randym

On Fri, May 2, 2014 at 9:22 PM, Felipe C.
<[email protected]

7

On 2 May 2014, at 15:49, Ricky Ng [email protected] wrote:

Or Rubyists are unable to understand the frustration that a language barrier has
created on an important module? And thus resort to labeling it as a racists rant
with remarks about leaving the community instead of attempting to understand the
issue at hand which is that Felipe cannot get a straightforward response about why
his proposed changes were rejected?

I fully understand the frustration. Ive been working with the other
ruby committers for over a decade and have been one for nearly half that
time. I have personally felt these feelings of frustration numerous
times.

Saying use English and western cultural norms, Japanese ones are not
good enough is racist.

tadf went to great lengths in #7445 to describe his reasoning for
rejection in the language he speaks well. If that isnt good enough for
Felipe he could have asked politely for translation assistance. Instead
we have this racist rant.

I really dont want to fix bugs for people that say such things and dont
want to welcome them into my community.

8

Hello,

Even though I can imagine your frustration (we had similar troubles
before among Japanese programmers), Tadayoshi is one of the best
programmers who knows about time and calendars, which are
unfortunately very difficult for various reasons.

This is very unfortunate miscommunication across language barrier.

As far as I understand, strptime with %s and %z combined is undefined.
because struct tm does not have timezone info. In the language
specification, “undefined” means you cannot expect anything, including
rejection as Tadayoshi did for DateTime.

%s means ‘time_t value from the epoch’. The epoch is fixed time point
(1979-01-01 00:00 UTC). Offsetting it according to %z seems nonsense,
or plain wrong. That’s the reason behid his rejection. If you were
lucky to read Japanese, you’d have understood it.

Besides that, you didn’t explain why you need to change the behavior.
Why do you want to do strptime("%s %z") at the first hand?

At least at the time of #7445, he didn’t reject the future
possibility, but he needs rational reason to change the undefined (and
conforming) behavior to the other undefined behavior. By ‘reason’, I
don’t mean the specific implementation behavor, nor wrong behavior.

          matz.

In message "Re: Who the fheck is Tadayoshi F. and why can he reject
sensible patches unilaterally?"
on Fri, 2 May 2014 15:22:55 -0500, Felipe C.
[email protected] writes:
|
|Hi,
|
|I’ve spent a lot of time trying to fix Ruby’s bad handling of the “%s
|%z” time format that is used in every Git commit. It’s now fixed for
|Time and in Rubinius both Time and DateTime without affecting anybody
|negatively.
|
|The only one remaining is DateTime, and as you can see in the bug
|report[1], the rationale is perfectly sensible, the fix simple, clean,
|and unobtrusive.
|
|Yet this guy, Tadayoshi F., closes it immediately without any
|reason given. After I complained he gives what is probably a bullshit
|reason, it’s hard to know because it’s in Japanese, but the code in
|the explanation is most definitely a red herring. This is probably due
|to an earlier discussion [2] in which he didn’t explain anything
|either.
|
|So my question is: who the fuck is this guy? And why can he just
|reject sensible patches like that?
|
|After a private discussion with somebody heavily involved in Ruby, I
|was enlightened to the fact that Ruby development is heavily
|influenced by Japanese culture, so every component has a clear
|maintainer, and he has the final word, regardless of their bullshit
|reasons.
|
|This model is clearly wrong. The most successful projects out there
|(e.g. Linux, Git) do not have maintainers making decisions
|unilaterally, but rather discussion and consensus are more important
|than authority. This ensures that if the maintainer is wrong (we are
|all wrong sometimes (some more than others)), the project doesn’t
|suffer as a result.
|
|If you must have a maintainer that makes decisions unilaterally,
|shouldn’t it be a sensible person able to communicate properly? This
|is something Tadayoshi F. is not. Apparently he cannot even speak
|English, so what is he doing maintaining a module of such an important
|project as Ruby?
|
|I believe this explains a lot about why Ruby has such a problem
|gaining and maintaining popularity. Even though the language is
|extremely awesome, the implementation cannot advance as it should,
|heavily in part due to this Japanese culture.
|
|This forces projects like Rubinius, and RubySL. I’ve talked to people
|in those projects who are heavily discontented with the way Ruby MRI
|does things; ignoring the larger community out there (who are not
|Japanese).
|
|For example, Ruby MRI doesn’t match the RubySpec, and why do the
|developers do? Nothing, ignore the RubySpec (at the moment of writing
|this I see 25 failures).
|
|If this political and cultural bullshit continues, I’m afraid Ruby
|won’t ever be as successful as similar but inferior languages such as
|Python, and whatever popularity it gains, it will quickly loose it as
|it did in 2008[3]. It will become a lost gem, like so many good
|Japanese things, only used in Japan (if at all), and ignored by the
|rest of the world.
|
|I hope Ruby becomes a sensible truly international project, adopt
|practices of other successful open source projects, and let go of this
|NIH bullshit.
|
|[1] Feature #9794: DateTime.strptime() doesn't work correctly for '%s %z' - Ruby master - Ruby Issue Tracking System
|[2] Bug #7445: strptime('%s %z') doesn't work - Ruby master - Ruby Issue Tracking System
|[3] Home - TIOBE
|
|–
|Felipe C.
|

9

On Fri, May 2, 2014 at 5:54 PM, Brandon W. [email protected]
wrote:

Perhaps the response was less than straightforward, but that does not excuse
the lack of tact in addressing it. There are far more civil ways to raise a
concern than this

Sure it doesn’t excuse that, but I think you should be more concerned
about the health of the project rather than how a particular small
contributor communicates himself.

10

On Fri, May 2, 2014 at 4:56 PM, Eric W. [email protected] wrote:

Felipe C. [email protected] wrote:

So my question is: who the f*uck is this guy?

Please relax, Felipe. I don’t know tadf, but I do know your attitude
on git-ML is not appreciated there, either.

My attitude might not be appreciated, but still I get my patches
merged (which benefit everyone), making me one of the top
contributors[1].

If your attitude were better, you may do a better job of convincing
people to accept your changes.

I’m #2 in the list of most prolific contributors in the Git project
for the last year[1]. I think I’m doing OK.

Maybe I could do better, sure, but I already got my patches to MRI’s
Time, and Rubinius Time and DateTime, so if I’m the problem here, how
did I manage to achieve that?

And instead of attacking me, how about you take a look at the actual
issue?

If tadf is wrong, then matz may override his decision. But please be
nice about it, it’s not the end of the world if a bug is not fixed.

Sure it is not the end of the world. But if a simple, straight-forward
bug that has already a fix, and it’s obvious to everyone (except one
person) that it’s correct, doesn’t get fixed and instead a bogus
explanation is given in a language that is spoken by less than 2% of
the population of world… that doesn’t give a pretty picture about
the health of the project, does it?

[1] https://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo

11

I’m equally concerned with both. Never underestimate the impact that the
attitude of contributors can have on a project.

Instead, seek to find understanding. It seems you still do not
understand
the point.

On Fri, May 2, 2014 at 9:05 PM, Felipe C.
<[email protected]

12

On Fri, May 2, 2014 at 9:10 PM, Brandon W. [email protected]
wrote:

I’m equally concerned with both. Never underestimate the impact that the
attitude of contributors can have on a project.

I would be concerned about long-time contributors that have a deep
impact on the project.

Not contributors that provide a couple of patches now and then.

13

On Fri, May 2, 2014 at 5:57 PM, Eric H. [email protected] wrote:

Saying “use English and western cultural norms, Japanese ones are not good
enough” is racist.

And who is saying that?

English is the de facto international language. Any project that aims
to be a successful open source project cannot shy away from English
since the vast majority of potential contributors could only
communicate by speaking English.

Additionally, any open source project that aims to be successful
cannot leave decisions to be made unilaterally and disregard
consensus.

14

Again, there are far far more professional ways to address things like
this. No matter how right you may be, being crude and disrespectful will
get you no where. Learn to be more patient and understanding of things,
be
more empathetic. I say this because you’re only doing yourself a
disservice
by continuing this, and you could be so much more than that.

Just calm down mate, all works out in due time.

On Fri, May 2, 2014 at 10:33 PM, Felipe C. <

15

On Fri, May 2, 2014 at 7:50 PM, Yukihiro M. [email protected]
wrote:

Even though I can imagine your frustration (we had similar troubles
before among Japanese programmers), Tadayoshi is one of the best
programmers who knows about time and calendars, which are
unfortunately very difficult for various reasons.

That might be the case, but his expertise in time and calendars give
him the right to reject fixes that everybody else (except him) have
agreed are correct?

This is very unfortunate miscommunication across language barrier.

I hope it is just that.

As far as I understand, strptime with %s and %z combined is undefined.
because struct tm does not have timezone info. In the language
specification, “undefined” means you cannot expect anything, including
rejection as Tadayoshi did for DateTime.

Yes, that is correct, you can consider “%s %z” as undefined in POSIX,
however by that rationale “%z” is undefined too[1], even “%s”. Both
“%s” and “%z” are GNU extensions for strptime()[2].

POSIX does define “%z” for strftime()[3], but not “%s”, that comes
from the Olson timezone package.

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”?

%s means ‘time_t value from the epoch’. The epoch is fixed time point
(1979-01-01 00:00 UTC). Offsetting it according to %z seems nonsense,
or plain wrong. That’s the reason behid his rejection. If you were
lucky to read Japanese, you’d have understood it.

Actually, the epoch is “1970-01-01 00:00 UTC” (not 1979), but that
doesn’t mean the epoch cannot be represented in different timezones.

For example:

d1 = DateTime.parse(“1970-01-01 00:00 UTC”)
d2 = DateTime.parse(“1970-01-01 01:00 +0100”)
d1 == d2
=> true

They are the same: the epoch. That means at 01:00 in Amsterdam, it was
00:00 in London: same date-time.

By saying UTC they don’t mean “%s” can only be represented in UTC,
they mean when London had the time “1970-01-01 00:00”, not Amsterdam.
I was confused about this at first too.

And then even if what you say is true that “%s” should only be UTC,
then why do we have this?

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

If strptime(‘0 +0100’, ‘%s %z’) should assume it’s UTC, then so should
strftime(“%s %z”).

Besides that, you didn’t explain why you need to change the behavior.
Why do you want to do strptime("%s %z") at the first hand?

I think I did: that’s the format Git uses to store dates on every
commit[4].

At least at the time of #7445, he didn’t reject the future
possibility, but he needs rational reason to change the undefined (and
conforming) behavior to the other undefined behavior. By ‘reason’, I
don’t mean the specific implementation behavor, nor wrong behavior.

How many more reasons do you need?

  1. GNU libc supports this
  2. Perl supports this
  3. Rubinius supports this
  4. Ruby MRI’s Time supports this
  5. Ruby MRI’s DateTime.strftime() supports this
  6. It’s a widely used format used by all Git commits

I mean, seriously, what more do you need?

I have provided multiple reasons why this is desirable, but how about
you provide a single reason why “%s %z” should ignore the
time-zone. Can you do that?

Cheers.

cat > test.c <<\EOF
#define _XOPEN_SOURCE
#include <stdio.h>
#include <time.h>

int main(int argc, char *argv[])
{
struct tm tm;
char buf[0x100];
strptime(argv[1], “%s %z”, &tm);
strftime(buf, sizeof(buf), “%s %z”, &tm);
printf(“%s\n”, buf);
return 0;
}
EOF

gcc test.c -o test

./test “0 +0100”
=> 0 +0100

[1]
http://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html
[2] strptime(3) - Linux man page
[3]
strftime
[4] Git - Git Objects

16

Hi,

In message “Re: Who the f*heck is Tadayoshi F. and why can he reject
sensible patches unilaterally?”
on Fri, 2 May 2014 22:33:21 -0500, Felipe C.
[email protected] 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).

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.

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.

          matz.

|> %s means ‘time_t value from the epoch’. The epoch is fixed time point
|> (1979-01-01 00:00 UTC). Offsetting it according to %z seems nonsense,
|> or plain wrong. That’s the reason behid his rejection. If you were
|> lucky to read Japanese, you’d have understood it.
|
|Actually, the epoch is “1970-01-01 00:00 UTC” (not 1979), but that
|doesn’t mean the epoch cannot be represented in different timezones.
|
|For example:
|
| d1 = DateTime.parse(“1970-01-01 00:00 UTC”)
| d2 = DateTime.parse(“1970-01-01 01:00 +0100”)
| d1 == d2
| => true
|
|They are the same: the epoch. That means at 01:00 in Amsterdam, it was
|00:00 in London: same date-time.
|
|By saying UTC they don’t mean “%s” can only be represented in UTC,
|they mean when London had the time “1970-01-01 00:00”, not Amsterdam.
|I was confused about this at first too.
|
|And then even if what you say is true that “%s” should only be UTC,
|then why do we have this?
|
| DateTime.parse(“1970-01-01 01:00 +0100”).strftime(“%s %z”)
| => “0 +0100”
|
|If strptime(‘0 +0100’, ‘%s %z’) should assume it’s UTC, then so should
|strftime(“%s %z”).
|
|> Besides that, you didn’t explain why you need to change the behavior.
|> Why do you want to do strptime("%s %z") at the first hand?
|
|I think I did: that’s the format Git uses to store dates on every commit[4].
|
|> At least at the time of #7445, he didn’t reject the future
|> possibility, but he needs rational reason to change the undefined (and
|> conforming) behavior to the other undefined behavior. By ‘reason’, I
|> don’t mean the specific implementation behavor, nor wrong behavior.
|
|How many more reasons do you need?
|
|1) GNU libc supports this
|2) Perl supports this
|3) Rubinius supports this
|4) Ruby MRI’s Time supports this
|5) Ruby MRI’s DateTime.strftime() supports this
|6) It’s a widely used format used by all Git commits
|
|I mean, seriously, what more do you need?
|
|I have provided multiple reasons why this is desirable, but how about
|you provide a single reason why “%s %z” should ignore the
|time-zone. Can you do that?
|
|Cheers.
|
| cat > test.c <<\EOF
| #define _XOPEN_SOURCE
| #include <stdio.h>
| #include <time.h>
|
| int main(int argc, char *argv[])
| {
| struct tm tm;
| char buf[0x100];
| strptime(argv[1], “%s %z”, &tm);
| strftime(buf, sizeof(buf), “%s %z”, &tm);
| printf(“%s\n”, buf);
| return 0;
| }
| EOF
|
| gcc test.c -o test
|
| ./test “0 +0100”
| => 0 +0100
|
|[1] strptime
|[2] strptime(3) - Linux man page
|[3] strftime
|[4] Git - Git Objects
|
|–
|Felipe C.
|

17

On Fri, May 2, 2014 at 10:33 PM, Felipe C.
[email protected] wrote:

By saying UTC they don’t mean “%s” can only be represented in UTC,
they mean when London had the time “1970-01-01 00:00”, not Amsterdam.
I was confused about this at first too.

Further proof of this, check this C program:

setenv(“TZ”, “UTC”, 1);
strptime(“0”, “%s”, &tm);
strftime(buf, sizeof(buf), “%s”, &tm);
printf(“%s\n”, buf);
setenv(“TZ”, “UTC+1”, 1);
strftime(buf, sizeof(buf), “%s”, &tm);
printf(“%s\n”, buf);
=> 0
=> 3600

Why is the result different if it’s the same date? That’s because “%s”
returns a local date compared to the epoch (UTC). That means “%s”
would return 0 at the epoch in London, but would return 3600 in
Amsterdam.

This makes sense since “struct tm” as specified by POSIX doesn’t
contain any timezone information, so what could “%z” possibly do? It
adds the local time-zone.

The documentation explains that:

    If a struct tm broken-down time structure is created by

localtime() or
localtime_r(), or modified by mktime(), and the value of TZ is
subsequently modified, the results of the %Z and %z strftime()
conversion specifiers are undefined, when strftime() is called
with
such a broken-down time structure.

So, yeah, “%s” doesn’t imply UTC.

18

On Sat, May 3, 2014 at 12:15 AM, Felipe C.
[email protected] wrote:

strptime(“0”, “%s”, &tm);
strftime(buf, sizeof(buf), “%s”, &tm);
printf(“%s\n”, buf);
setenv(“TZ”, “UTC+1”, 1);
strftime(buf, sizeof(buf), “%s”, &tm);
printf(“%s\n”, buf);
=> 0
=> 3600

Actually this is not correct:

setenv(“TZ”, “UTC”, 1);
tzset();
strptime(“0”, “%s”, &tm);
strftime(buf, sizeof(buf), “%s %z”, &tm);
printf(“%s\n”, buf);
strftime(buf, sizeof(buf), “%F %T %z”, &tm);
printf(“%s\n”, buf);
time = mktime(&tm);
setenv(“TZ”, “UTC-1”, 1);
tzset();
localtime_r(&time, &tm);
strftime(buf, sizeof(buf), “%s %z”, &tm);
printf(“%s\n”, buf);
strftime(buf, sizeof(buf), “%F %T %z”, &tm);
printf(“%s\n”, buf);

=> 0 +0000
=> 1970-01-01 00:00:00 +0000
=> 0 +0100
=> 1970-01-01 01:00:00 +0100

So all 4 dates correspond to the same date: the epoch, and this is
what the patch does:

DateTime.strptime(‘0 +0100’, ‘%s %z’) == DateTime.strptime(‘0 +0000’,
‘%s %z’)
=> true

19

So all 4 dates correspond to the same date: the epoch, and this is
what the patch does:

DateTime.strptime(‘0 +0100’, ‘%s %z’) == DateTime.strptime(‘0 +0000’,
‘%s %z’)
=> true

Ruby does exactly that today. Are we actually having a conversation over

DateTime.strptime(‘0 +0100’, “%s %z”).to_s
=> “1970-01-01T00:00:00+00:00”
vs
DateTime.strptime(‘0 +0100’, “%s %z”).to_s
=> “1970-01-01T01:00:00+01:00”

??? Because that’s an extraordinary weird conversation to have as
passionately as you appear to want to have this one…

DateTime.strptime(‘0 +0100’, ‘%s %z’) == DateTime.strptime(‘0 +0000’,
‘%s
%z’) is already true

So I’m wondering what else is left at this point?

John

20

On Sat, May 3, 2014 at 12:56 AM, Yukihiro M. [email protected]
wrote:

|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] Slippery slope - Wikipedia