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

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 Funaba, 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 Funaba 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] https://bugs.ruby-lang.org/issues/9794
[2] https://bugs.ruby-lang.org/issues/7445
[3] http://www.tiobe.com/index.php/content/paperinfo/tpci/Ruby.html

···

--
Felipe Contreras

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

I think you should find a different language.

···

On 2 May 2014, at 13:22, Felipe Contreras <felipe.contreras@gmail.com> 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 Funaba 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.

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.

···

Felipe Contreras <felipe.contreras@gmail.com> wrote:

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

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 Contreras <felipe.contreras@gmail.com > wrote:

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 Funaba, 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 Funaba 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 Contreras

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 f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?" on Fri, 2 May 2014 15:22:55 -0500, Felipe Contreras <felipe.contreras@gmail.com> 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 Funaba, 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 Funaba 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 Contreras

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?

···

On Fri, May 2, 2014 at 5:24 PM, Eric Hodel <drbrain@segment7.net> wrote:

On 2 May 2014, at 13:22, Felipe Contreras <felipe.contreras@gmail.com> > 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 Funaba 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.

--
Incoherently,
Ricky Ng

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

···

On Fri, May 2, 2014 at 4:56 PM, Eric Wong <normalperson@yhbt.net> wrote:

Felipe Contreras <felipe.contreras@gmail.com> wrote:

--
Felipe Contreras

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] strptime
[2] http://linux.die.net/man/3/strptime
[3] strftime
[4] Git - Git Objects

···

On Fri, May 2, 2014 at 7:50 PM, Yukihiro Matsumoto <matz@ruby.or.jp> wrote:

--
Felipe Contreras


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 Contreras < felipe.contreras@gmail.com> wrote:

On Fri, May 2, 2014 at 7:50 PM, Yukihiro Matsumoto <matz@ruby.or.jp> > 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] strptime
[2] http://linux.die.net/man/3/strptime
[3] strftime
[4] Git - Git Objects

--
Felipe Contreras

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

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.

···

On Fri, May 2, 2014 at 10:33 PM, Felipe Contreras <felipe.contreras@gmail.com> 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.

--
Felipe Contreras

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

···

On Sat, May 3, 2014 at 12:15 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

On Fri, May 2, 2014 at 10:33 PM, Felipe Contreras > <felipe.contreras@gmail.com> 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

--
Felipe Contreras

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.

Yes it does, I wasn't arguing otherwise, my point was that the
behavior wasn't broken, even though I understood it wrongly from the C
program above.

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"

Yes we do.

This is also true:

  DateTime.parse('1970-01-01T01:00:00+01:00') ==
DateTime.parse('1970-01-01T00:00:00+00:00')
  => true

But do you think therefore this would be just fine?

DateTime.parse('1970-01-01T01:00:00+01:00').to_s
  => "1970-01-01T00:00:00+00:00"

It's the same date.

But there's a reason why the timezone was put there in the first
place, and there's a reason why Ruby stores it correct. The timezone
matters.

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

To apply the patch so that the timezone is stored and displayed correctly.

···

On Sat, May 3, 2014 at 1:44 AM, John W Higgins <wishdev@gmail.com> wrote:

--
Felipe Contreras

I sort of get stuck here don't I?

On one hand one must admire to some degree the passion of someone who
actually is that invested in this to get this involved in something
"somewhat trivial" at the end of the day. That's not to downgrade your
passion - because it's certainly something I would love to see more from my
co-workers on a daily basis.

On the other hand - I'm not sure the sky is falling here - does it really
matter that much that you would drop napalm on people to make sure it was
accomplished?

I think if you presented your case that you simply where asking for the
timezone to be stored with no modifications to the underlying datetime then
you might have gotten/can easily get more traction here.

So if I've helped you in any way better explain your goal then I wish you
nothing but the best in your mission.......

John

···

On Sat, May 3, 2014 at 12:16 AM, Felipe Contreras < felipe.contreras@gmail.com> wrote:

...
But do you think therefore this would be just fine?

DateTime.parse('1970-01-01T01:00:00+01:00').to_s
  => "1970-01-01T00:00:00+00:00"

It's the same date.

On one hand one must admire to some degree the passion of someone who
actually is that invested in this to get this involved in something
"somewhat trivial" at the end of the day. That's not to downgrade your
passion - because it's certainly something I would love to see more from my
co-workers on a daily basis.

On the other hand - I'm not sure the sky is falling here - does it really
matter that much that you would drop napalm on people to make sure it was
accomplished?

The bug itself doesn't matter much, that's true. Although I've spent a
huge amount of time in this, much more than it would have been
required in other projects, and believe me, I've contributed to a lot
of projects[1].

What does matter is *why* this patch is not applied, and *how* it's
being rejected.

I really love the Ruby language, and I really want it to succeed, and
I just can't understand why it's not more popular right now.

It's because of trivial issues like this that I'm starting to realize
why it's never going to get any better.

I think if you presented your case that you simply where asking for the
timezone to be stored with no modifications to the underlying datetime then
you might have gotten/can easily get more traction here.

That's exactly what I did in October of last year[2]. Can you guess
what happened to DateTime?

[1] https://www.ohloh.net/accounts/felipec/positions
[2] http://article.gmane.org/gmane.comp.lang.ruby.core/56990

···

On Sat, May 3, 2014 at 11:05 AM, John W Higgins <wishdev@gmail.com> wrote:

--
Felipe Contreras

I fully understand the frustration. I’ve 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 isn’t good enough for Felipe he could have asked politely for translation assistance. Instead we have this racist rant.

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

···

On 2 May 2014, at 15:49, Ricky Ng <dummey@gmail.com> 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?

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.

···

On Fri, May 2, 2014 at 5:49 PM, Ricky Ng <dummey@gmail.com> 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?

On Fri, May 2, 2014 at 5:24 PM, Eric Hodel <drbrain@segment7.net> wrote:

On 2 May 2014, at 13:22, Felipe Contreras <felipe.contreras@gmail.com> >> 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 Funaba 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.

--
Incoherently,
Ricky Ng

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.

···

On Fri, May 2, 2014 at 5:57 PM, Eric Hodel <drbrain@segment7.net> wrote:

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

--
Felipe Contreras

Hi,

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.

···

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:

%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] http://linux.die.net/man/3/strptime
[3] strftime
[4] Git - Git Objects

--
Felipe Contreras

Quoting Felipe Contreras (felipe.contreras@gmail.com):

It's because of trivial issues like this that I'm starting to realize
why it's never going to get any better.

It is constantly getting better. It may not be getting more *popular*
(although I have no hard data on this). The two things are quite
apart. Anyway, I for one am very proud of how the development of my
favorite language is being carried on. Many thanks + arigato to all of
you out there.

Carlo

···

Subject: Re: Who the f*heck is Tadayoshi Funaba and why can he reject sensible patches unilaterally?
  Date: sab 03 mag 14 01:23:52 -0500

--
  * Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)