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

1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-02 22:23
(Received via mailing list)
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/t...
18813f71506ebad74179bf8c5a136696?d=identicon&s=25 Eric Wong (Guest)
on 2014-05-02 23:56
(Received via mailing list)
Felipe Contreras <felipe.contreras@gmail.com> 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.
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2014-05-03 00:34
(Received via mailing list)
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.
20753db11b9ffec13351e7fc2ddfbf7e?d=identicon&s=25 Ricky N. (ricky_n)
on 2014-05-03 00:49
(Received via mailing list)
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?
F555402e879ef6ad937e41bbaedb465b?d=identicon&s=25 Brandon W. (brandon_w)
on 2014-05-03 00:55
(Received via mailing list)
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.
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2014-05-03 00:58
(Received via mailing list)
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?

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.
855975ff404621dc525c72b618d95dcc?d=identicon&s=25 Randy Morgan (randym)
on 2014-05-03 01:16
(Received via mailing list)
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
6738588a11b852833edf6aec90ef6fa3?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2014-05-03 02:50
(Received via mailing list)
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] https://bugs.ruby-lang.org/issues/9794
|[2] https://bugs.ruby-lang.org/issues/7445
|[3] http://www.tiobe.com/index.php/content/paperinfo/t...
|
|--
|Felipe Contreras
|
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 03:59
(Received via mailing list)
On Fri, May 2, 2014 at 4:56 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> 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=&so...
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 04:05
(Received via mailing list)
On Fri, May 2, 2014 at 5:54 PM, Brandon Weaver <keystonelemur@gmail.com>
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.
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 04:11
(Received via mailing list)
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.

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.
F555402e879ef6ad937e41bbaedb465b?d=identicon&s=25 Brandon W. (brandon_w)
on 2014-05-03 04:11
(Received via mailing list)
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 Contreras
<felipe.contreras@gmail.com
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 05:33
(Received via mailing list)
On Fri, May 2, 2014 at 9:10 PM, Brandon Weaver <keystonelemur@gmail.com>
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.
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 05:34
(Received via mailing list)
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]
http://pubs.opengroup.org/onlinepubs/009695399/fun...
[2] http://linux.die.net/man/3/strptime
[3]
http://pubs.opengroup.org/onlinepubs/009695399/fun...
[4] http://git-scm.com/book/en/Git-Internals-Git-Objects
F555402e879ef6ad937e41bbaedb465b?d=identicon&s=25 Brandon W. (brandon_w)
on 2014-05-03 05:59
(Received via mailing list)
http://pbs.twimg.com/media/BmPom4aCcAI9fhG.png:medium

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 <
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 07:15
(Received via mailing list)
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

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.
6738588a11b852833edf6aec90ef6fa3?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2014-05-03 07:57
(Received via mailing list)
Hi,

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).

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] http://pubs.opengroup.org/onlinepubs/009695399/fun...
|[2] http://linux.die.net/man/3/strptime
|[3] http://pubs.opengroup.org/onlinepubs/009695399/fun...
|[4] http://git-scm.com/book/en/Git-Internals-Git-Objects
|
|--
|Felipe Contreras
|
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 08:10
(Received via mailing list)
On Sat, May 3, 2014 at 12:15 AM, Felipe Contreras
<felipe.contreras@gmail.com> 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
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 08:32
(Received via mailing list)
On Sat, May 3, 2014 at 12:56 AM, Yukihiro Matsumoto <matz@ruby.or.jp>
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] http://en.wikipedia.org/wiki/Slippery_slope
60b83bb4579cd684731a1709f85ee849?d=identicon&s=25 John W Higgins (Guest)
on 2014-05-03 08:45
(Received via mailing list)
>
>
> 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
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 09:17
(Received via mailing list)
On Sat, May 3, 2014 at 1:44 AM, John W Higgins <wishdev@gmail.com>
wrote:
>>
>> 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.
6738588a11b852833edf6aec90ef6fa3?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2014-05-03 16:28
(Received via mailing list)
Hello,

In message "Re: Who the f*heck is Tadayoshi Funaba and why can he reject
sensible patches unilaterally?"
    on Sat, 3 May 2014 01:32:09 -0500, Felipe Contreras
<felipe.contreras@gmail.com> writes:

|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"

According to the discussion in Japanese, formatting (output) is OK,
but parsing is not.  For example, "Sat May 3 00:00:00 2014" can be
parsed as a correct date, but "Fri May 3 00:00:00 2014" is not,
because it contains contradicting information.  Hence at least some
part of the original string should be ignored.  That wouldn't happen
in output.  According to Tadayoshi's opinion, time_t (%s)
fundamentally comes without timezone information from its definition,
so that the combination is meaningless, thus ignored.

I know unlike day of the week, timezone information does not
contradict with time_t.  They are independent.  I don't think his
opinion is universal truth, but at least I respect his opinion.
When our opinions differ, I try to persuade.

So please tell me, why do you want to parse date strings in form of
"%s %z"?  Just for consistency?  Or something git related?  If git
somehow uses this kind of strings pretty often, that fact might be a
good reason to support.  Otherwise you can always use _strptime()
method, which parses and retrieves as much information it finds, as
Tadayoshi stated before.

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

Because whole date/datetime is his masterpiece.  He designed and
implemented it from scratch.  He has been maintained it for long time.
I don't want to force him in any way just because his work is bundled
with Ruby.  Just like I don't want to be forced to do anything just
because of Ruby is a part of something, e.g. a Linux distribution.

Once I asked him for permission to bundle his work with Ruby, but I
didn't take it away from him.  I don't want to lose him, nor date
subsystem, his long time effort and huge contribution to the Ruby
world, just because our opinion is different in corner cases.

              matz.
60b83bb4579cd684731a1709f85ee849?d=identicon&s=25 John W Higgins (Guest)
on 2014-05-03 18:06
(Received via mailing list)
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.
>
>
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
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 20:24
(Received via mailing list)
On Sat, May 3, 2014 at 11:05 AM, John W Higgins <wishdev@gmail.com>
wrote:

> 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
3853dd5371ac1e094fc45d6c2aa0e459?d=identicon&s=25 Carlo E. Prelz (Guest)
on 2014-05-03 20:37
(Received via mailing list)
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

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
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 21:25
(Received via mailing list)
On Sat, May 3, 2014 at 9:27 AM, Yukihiro Matsumoto <matz@ruby.or.jp>
wrote:

> |for "%s %z" in several places. I would really like an answer to that.
> fundamentally comes without timezone information from its definition,
> so that the combination is meaningless, thus ignored.

Come on, time_t is irrelevant, we are talking about Ruby, and DateTime
does have an offset field, it doesn't rely solely on a large integer
like time_t. We don't have the limitations the C standard has.

> I know unlike day of the week, timezone information does not
> contradict with time_t.  They are independent.  I don't think his
> opinion is universal truth, but at least I respect his opinion.
> When our opinions differ, I try to persuade.

Exactly.

> So please tell me, why do you want to parse date strings in form of
> "%s %z"?  Just for consistency?  Or something git related?  If git
> somehow uses this kind of strings pretty often, that fact might be a
> good reason to support.  Otherwise you can always use _strptime()
> method, which parses and retrieves as much information it finds, as
> Tadayoshi stated before.

I already explained that Git uses this format to store dates, so it's
used on *every* *single* *commit* (twice). I thought that was already
evident, but apparently I must make it clearer.

Here, I wrote a simple parser[1] to exemplify this. It takes the raw
commit information stores it in a Ruby object, and then I try to print
this object back.

So would expect this:

  % git cat-file -p HEAD > expected
  % ruby git-parser HEAD > actual
  % diff -u expected actual

To show no diff, but instead I get this:

  --- expected 2014-05-03 14:04:13.300651626 -0500
  +++ actual 2014-05-03 14:03:59.076651245 -0500
  @@ -1,8 +1,8 @@
   tree 90046017e7ce9711ab0c732f46a24b7968c351c2
   parent b2feb643097a1ec0cbe79fc161f604b6265c049b
   parent 94f94fcbf2b1009da358fbe06edffbd206d9fa7a
  -author Junio C Hamano <gitster@pobox.com> 1398880902 -0700
  -committer Junio C Hamano <gitster@pobox.com> 1398880902 -0700
  +author Junio C Hamano <gitster@pobox.com> 1398880902 +0000
  +committer Junio C Hamano <gitster@pobox.com> 1398880902 +0000

   Merge git://github.com/git-l10n/git-po

Clearly, Ruby MRI's DateTime is unable to parse Git commits.

> |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?
>
> Because whole date/datetime is his masterpiece.  He designed and
> implemented it from scratch.  He has been maintained it for long time.
> I don't want to force him in any way just because his work is bundled
> with Ruby.  Just like I don't want to be forced to do anything just
> because of Ruby is a part of something, e.g. a Linux distribution.

That is a bad analogy. Ruby is part of many distributions. His code is
not part of many projects.

In fact, this is not how people think in open source projects. It's
not his code, it's the projects' code. In fact, not even that, the
project belongs to the public domain.

> Once I asked him for permission to bundle his work with Ruby, but I
> didn't take it away from him.  I don't want to lose him, nor date
> subsystem, his long time effort and huge contribution to the Ruby
> world, just because our opinion is different in corner cases.

If you lose him because of a disagreement on how "%s %z" should be
parsed (and he disagrees with everyone on this), maybe he wasn't worth
working with in the first place.

Cheers.

[1] http://pastie.org/9137204
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 21:28
(Received via mailing list)
On Sat, May 3, 2014 at 1:36 PM, Carlo E. Prelz <fluido@fluido.as> wrote:
> 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.

Indeed, the language is getting better, but not as much as it could,
and not as fast as it could. Specially considering the huge amount of
people that stay away from Ruby MRI where they could be contributing
to it.

But by getting better I didn't mean the language itself, I meant the
popularity of it.
D2bff075522befb15313dab85f3a671b?d=identicon&s=25 Kevin Walzer (codebykevin)
on 2014-05-03 22:05
(Received via mailing list)
On 5/3/14, 3:24 PM, Felipe Contreras wrote:
> If you lose him because of a disagreement on how "%s %z" should be
> parsed (and he disagrees with everyone on this), maybe he wasn't worth
> working with in the first place.

In most open source projects, maintainers of a module/library/component
of the core library are the final arbiter of what patches are accepted
into their domain. Patches may be rejected for any reason or no reason.

Speaking as the maintainer of a significant upstream component of Ruby
(Tk's Mac bindings), I am grateful for patches. The submitter may very
well be smarter than me about the subject in question and I am happy to
commit their patch if the use-case is reasonably well-explained, and
causes no side-effects when applied.

However, sometimes I do not accept patches. This could be because I
don't understand the use case for the patch, do not agree with the
solution to the problem, or do not agree that the issue in question *is*
a problem. In such cases, the only time I would expect to be
second-guessed by another member of the project would be if their
technical expertise were greater than or equal to mine.

In most cases, the "consensus" you are looking for simply does not
exist. Patches are not reviewed by a committee, patches are typically
reviewed by individuals who provide expertise that other members of the
project lack. If an individual with unique or significant expertise
leaves a project, there simply may not be anyone to replace him or her.
When the maintainer involved is the original author of the code, this is
especially true. Matz has indicated as much with the maintainer in
question.

I can also echo others in this thread that the arrogance you have
displayed in your comments far overshadows any technical merit your
arguments might have. In my own domain, I welcome constructive
disagreement and can even be persuaded by it, but if you come at me with
the kind of combative attitude you have displayed, I will end the
discussion quickly and advise you to maintain your own fork of the code
with your patch applied--that is, after all, one of the benefits of open
source.

--Kevin
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 22:33
(Received via mailing list)
On Sat, May 3, 2014 at 3:05 PM, Kevin Walzer <kw@codebykevin.com> wrote:
> On 5/3/14, 3:24 PM, Felipe Contreras wrote:
>>
>> If you lose him because of a disagreement on how "%s %z" should be
>> parsed (and he disagrees with everyone on this), maybe he wasn't worth
>> working with in the first place.
>
> In most open source projects, maintainers of a module/library/component of
> the core library are the final arbiter of what patches are accepted into
> their domain. Patches may be rejected for any reason or no reason.

That is simply not true.

> of the project would be if their technical expertise were greater than or
> equal to mine.

In most projects when one or more maintainers of other modules might
disagree, and then there's always a leader (e.g. Linus Torvalds) that
makes the final decision. So no, in most projects the module
maintainers are not the final arbiters of what goes in those modules.

> In most cases, the "consensus" you are looking for simply does not exist.

But in this case there is. That's why Time.strptime() got fixed,
Rubinius's Time.strptime() got fixed, and Rubinius DateTime.strptime()
got fixed.

> Patches are not reviewed by a committee, patches are typically reviewed by
> individuals who provide expertise that other members of the project lack. If
> an individual with unique or significant expertise leaves a project, there
> simply may not be anyone to replace him or her. When the maintainer involved
> is the original author of the code, this is especially true. Matz has
> indicated as much with the maintainer in question.

There is a concept know as the "bus factor" that measures how
concentrated is the knowledge shared in the team. If losing a single
developer can cause such big problems, that's not ideal.

> I can also echo others in this thread that the arrogance you have displayed
> in your comments far overshadows any technical merit your arguments might
> have. In my own domain, I welcome constructive disagreement and can even be
> persuaded by it, but if you come at me with the kind of combative attitude
> you have displayed, I will end the discussion quickly and advise you to
> maintain your own fork of the code with your patch applied--that is, after
> all, one of the benefits of open source.

So you don't care what is better for the Ruby project, you just want
to have nice and pleasant discussions. Got it.

[1] http://en.wikipedia.org/wiki/Bus_factor
F555402e879ef6ad937e41bbaedb465b?d=identicon&s=25 Brandon W. (brandon_w)
on 2014-05-03 22:51
(Received via mailing list)
The two are not mutually exclusive. There's no reason why people cannot
be
civil AND improve the community. Pretending it's a non-issue is only
doing
yourself a disservice. If anything I feel you should apologize for your
rudeness to the core committers, it's completely unwarranted.


On Sat, May 3, 2014 at 3:33 PM, Felipe Contreras
<felipe.contreras@gmail.com
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-03 23:14
(Received via mailing list)
On Sat, May 3, 2014 at 3:51 PM, Brandon Weaver <keystonelemur@gmail.com>
wrote:
> The two are not mutually exclusive.

And who argued they were?

Besides it's a red herring, Kevin was talking about a hypothetical
situation where a person with combative attitude tried to persuade
him.

In that situation he specifically said he didn't care if such person
was right, therefore he didn't care if the proposed change would
improve the project.

> Pretending it's a non-issue is only doing
> yourself a disservice. If anything I feel you should apologize for your
> rudeness to the core committers, it's completely unwarranted.

I won't.

If you don't want to fix Ruby's broken DateTime.strptime's handling of
"%s %z" because some guy didn't apologize, that says to me that your
priorities are wrong, and that improving Ruby is definitely not as
high as it should be.
5a837592409354297424994e8d62f722?d=identicon&s=25 Ryan Davis (Guest)
on 2014-05-03 23:28
(Received via mailing list)
On May 3, 2014, at 7:27, Yukihiro Matsumoto <matz@ruby.or.jp> wrote:

Matz, thanks for taking the time to deal with this.

It is much appreciated by at least some of us. :)

> According to the discussion in Japanese, formatting (output) is OK,
> but parsing is not.  For example, "Sat May 3 00:00:00 2014" can be
> parsed as a correct date, but "Fri May 3 00:00:00 2014" is not,
> because it contains contradicting information.  Hence at least some
> part of the original string should be ignored.  That wouldn't happen
> in output.  According to Tadayoshi's opinion, time_t (%s)
> fundamentally comes without timezone information from its definition,
> so that the combination is meaningless, thus ignored.

DateTime.strptime defers to the man-page for strptime for almost it's
entire definition:

> 10004 % ri DateTime.strptime | tail -3 | head -1
> See also strptime(3) and strftime.

(from a previous email):

> 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.

And the man-page explicitly states that resulting values are relative to
the local time zone:

> 10009 % man 3 strptime | grep -C2 relative | head -5
>      The strptime() function parses the string in the buffer buf, according to
>      the string pointed to by format, and fills in the elements of the struc-
>      ture pointed to by tm.  The resulting values will be relative to the
>      local time zone.  Thus, it can be considered the reverse operation of
>      strftime(3).

This implies that DateTime.strptime isn't living up to it's contract,
yes?
D2bff075522befb15313dab85f3a671b?d=identicon&s=25 Kevin Walzer (codebykevin)
on 2014-05-03 23:33
(Received via mailing list)
On 5/3/14, 4:33 PM, Felipe Contreras wrote:
>>
>> In most open source projects, maintainers of a module/library/component of
>> the core library are the final arbiter of what patches are accepted into
>> their domain. Patches may be rejected for any reason or no reason.
>
> That is simply not true.

It's certainly true of all the projects I've been associated with:
Tcl/Tk, Emacs on the Mac, my own individual OSS projects. There is no
central set of rules that compel acceptance of a patch--it's always left
to the judgment of the individual maintainer.

> In most projects when one or more maintainers of other modules might
> disagree, and then there's always a leader (e.g. Linus Torvalds) that
> makes the final decision. So no, in most projects the module
> maintainers are not the final arbiters of what goes in those modules.

This depends on the project. Tcl/Tk, the project I work the most with,
lacks such a BDFL figure. John Osterhout, the inventor of Tcl, turned
maintenance of the language over to a core group that does not have a
single leader. While this group votes on significant new features or
additions to the language, it does not sign off on patches and bugfixes.

>> In most cases, the "consensus" you are looking for simply does not exist.
>
> But in this case there is. That's why Time.strptime() got fixed,
> Rubinius's Time.strptime() got fixed, and Rubinius DateTime.strptime()
> got fixed.

Maybe that's so, and maybe there is no technical reason for the patch
you've submitted to be rejected. But the maintainer has rejected it, and
(getting back to your earlier point) Matz has backed him despite your
protests. Based on your own stated criteria, it seems to me that this
means the subject is closed--unless you are implying Matz is wrong as
well.

>
> There is a concept know as the "bus factor" that measures how
> concentrated is the knowledge shared in the team. If losing a single
> developer can cause such big problems, that's not ideal.

No, it's not, but sometimes it's what a project has to work with. I have
less expertise than my predecessor as Mac maintainer of Tk (he works at
Apple now), but no one else stepped forward to replace him. It was me or
nobody. That's life in the open-source world.

>
> So you don't care what is better for the Ruby project, you just want
> to have nice and pleasant discussions. Got it.

I do care about the open-source projects I work with, and I do want them
to thrive. And, in my experience, civility is a better tool to achieving
those ends than flame wars. Really, do you have any appreciation of how
you are coming across? Suggesting that someone's nationality is to blame
for their rejecting your patch? Suggesting that the project would be
better off without them when the project leader has said they are
practically indispensable?

Though you're apparently scornful of civility, "nice and pleasant
discussions" can be a useful indicator of the health of an open-source
project. Tcl lags behind Ruby in its mindshare and the size of its
developer community, but it persists, in no small part because the
people associated with the community get along well, and are friendly
and helpful to newcomers--in addition to being brilliant and dedicated
engineers.

You might want to consider that you catch more flies with honey than you
do vinegar.

--Kevin
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-04 00:17
(Received via mailing list)
On Sat, May 3, 2014 at 4:32 PM, Kevin Walzer <kw@codebykevin.com> wrote:

> Matz has backed him despite your protests.

He has not backed him. If you din't read correctly he accepts the
timezone representation is independent of the date, that means he has
no problem in parsing it the way I propose.

He said he respected Tadayoshi's opinion, that doesn't mean he shares
it.

> And, in my experience, civility is a better tool to achieving those
> ends than flame wars.

Linux is a project well know for what some call "hostile environment",
however, it's the most successful software project in history by far.
And it's because of their no-bullshit attitude.

If we were in the LKML mailing list we would be discussing about the
patch and it's technical merits, and not this ad hominem bullshit.

You can listen from Linus' boss why "you don't always need to be
nice"[1]. There are even papers about it[2].

But I'm done talking about irrelevant stuff. Unless you have something
to say about the DateTime.strptime() bug, I'm not interested.

[1] https://www.youtube.com/watch?v=7XTHdcmjenI
[2]
http://www.ilr.cornell.edu/directory/ja26531/downl...
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2014-05-04 00:36
The problem with the thread starter, aside from the tone, is that
certain claims are just invariably and absolutely incorrect:

"This model is clearly wrong. The most successful projects out there
(e.g. Linux, Git) do not have maintainers making decisions unilaterally"

Ok so this is a wrong claim. Linus *does* make unilateral decisions and
always did. I don't know what the thread starter was smoking but clearly
he does not know how the linux kernel evolves.

Everyone who knows Linus knows that he gets to decide what is used and
what is not used. And since he does not like C++, there is no C++ in the
kernel - and by the way, matz also does not like C++. So if both Linus
and matz don't like C++ perhaps there is a high chance that they may be
right.

http://harmful.cat-v.org/software/c++/linus

"My attitude might not be appreciated, but still I get my patches merged
(which benefit everyone)"

I don't know. Matz is busy with mruby, so my favourite core guy is now
Nobuyoshi Nakada and also Kouhei Sutou simply because someone keeping
ruby-gnome/gtk alive and healthy.

Perhaps Felipe Contreras is more like pulling a zedshaw drama queen
move.

I reject the claim that Felipe Contreras's patches are absolutely vital
to have in the first place. There is no "ego" attached in C code.

"I'm #2 in the list of most prolific contributors in the Git project
for the last year. I think I'm doing OK."

I haven't heard of you so far. What cool ruby projects do you actually
have made available on rubygems.org? I searched and searched but I
failed to find anything of relevance. So perhaps your real contribution
is significantly lower than you think it is.

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

What problem existed in the first place? Probably some extremely low and
unimportant one that would have been discovered just as well by the
hundreds other devs out there who don't play a drama queen move.

I have more confidence in them than in you.

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

Not at all, that is your assumption here.

I have had some proposals to ruby, most got rejected, a few got in.

Ruby as a whole is rather conservative in regards to keeping the
features it has available. And whenever I started to suggest something
in english, all replies or comments (to me) also were in english.

And I understand the english written by just about all japanese devs;
the occasional mistakes are of no real importance as long as I
understand the main message.

Whether it is in english or not - I think the core of the issue is that
you are angry that your patch got rejected. In that case, it would not
make a big difference whether it is in japanese or in english.
D2bff075522befb15313dab85f3a671b?d=identicon&s=25 Kevin Walzer (codebykevin)
on 2014-05-04 00:37
(Received via mailing list)
On 5/3/14, 6:16 PM, Felipe Contreras wrote:
> On Sat, May 3, 2014 at 4:32 PM, Kevin Walzer <kw@codebykevin.com> wrote:
>
> Linux is a project well know for what some call "hostile environment",
> however, it's the most successful software project in history by far.
> And it's because of their no-bullshit attitude.

Yes, this is true. Linux is very reflective of the personality of its
leader. However, does this mean that every project functions this way,
or must?
>
> If we were in the LKML mailing list we would be discussing about the
> patch and it's technical merits, and not this ad hominem bullshit.

Yes, but this isn't the LKML mailing list, is it?

>
> You can listen from Linus' boss why "you don't always need to be
> nice"[1]. There are even papers about it[2].

If this were the Python, Tcl, Cocoa-dev, MacPorts, or Fink mailing
lists, consideration of your tone would be very much a subject of
discussion. Civility is an important value in many software communities
because it facilitates better work. Coming in with guns blazing,
demanding recognition of your technical brilliance and castigating
anyone who disagrees with you as an idiot is not constructive in many
communities, including here.

>
> But I'm done talking about irrelevant stuff. Unless you have something
> to say about the DateTime.strptime() bug, I'm not interested.

I have no opinion on the technical merits of your patch. My purpose, as
a software maintainer, was to shed a bit of light on why your patch may
have been rejected. That is, after, the subject of this thread.

I see you have set up a fork of git because your patches were not being
accepted. You might have less frustration if you were to do the same
with Ruby.

--Kevin
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-04 00:53
(Received via mailing list)
On Sat, May 3, 2014 at 5:36 PM, Kevin Walzer <kw@codebykevin.com> wrote:
.
> Civility is an important value in many software communities because it
> facilitates better work.

That is an *assumption* you hold, and it's not backed up by the
evidence I just presented.

>> But I'm done talking about irrelevant stuff. Unless you have something
>> to say about the DateTime.strptime() bug, I'm not interested.
>
> I have no opinion on the technical merits of your patch.

Then I see no reason to discuss with you.

> I see you have set up a fork of git because your patches were not being
> accepted.

The vast majority of my patches are accepted[1].

[1] https://www.ohloh.net/p/git/contributors?query=&so...
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-04 06:59
(Received via mailing list)
On Sat, May 3, 2014 at 9:27 AM, Yukihiro Matsumoto <matz@ruby.or.jp>
wrote:

> |for "%s %z" in several places. I would really like an answer to that.
> fundamentally comes without timezone information from its definition,
> so that the combination is meaningless, thus ignored.

Actually, just to make it clear, originally you said "%s" implies UTC,
but as I showed above DateTime.strtime() doesn't actually do that,
that was the point I wanted you to answer.

So do you agree now that "%s" does *not* imply UTC?
3853dd5371ac1e094fc45d6c2aa0e459?d=identicon&s=25 Carlo E. Prelz (Guest)
on 2014-05-04 08:20
(Received via mailing list)
Subject: Re: Who the f*heck is Tadayoshi Funaba and why can he reject
sensible patches unilaterally?
  Date: sab 03 mag 14 11:58:35 -0500

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

> Actually, just to make it clear, originally you said "%s" implies UTC,
> but as I showed above DateTime.strtime() doesn't actually do that,

I'd put it like this: %s already completely defines a coordinate in
time. If I say 'it's 4 may 2014, 8AM', that's not enough to place my
statement in a universal timeline - for that I have to add the
timezone information. But if I say 'it's 1399183200', the definition
is complete. What you don't have is any information about my *space*
coordinate. But strtime is about time, not space.

If you provide both %s and %z, you provide *too much* information. As
anyone who studied static knows, if you provide too many resting
points you obtain instability.

I share Tadayoshi-san's conclusions. I believe the best way to
proceed, if you need to regularly parse that specific format, is to
code an ad-hoc extension, appropriately named and documented.

Carlo
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-04 08:39
(Received via mailing list)
On Sun, May 4, 2014 at 1:19 AM, Carlo E. Prelz <fluido@fluido.as> wrote:
> statement in a universal timeline - for that I have to add the
> timezone information. But if I say 'it's 1399183200', the definition
> is complete. What you don't have is any information about my *space*
> coordinate. But strtime is about time, not space.

Yes, I understand that.

> If you provide both %s and %z, you provide *too much* information.

But we already have that information!

Here, I'll put it yet one more time:

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

If we follow your rationale, that should return "0 +0000", or maybe even
fail.

But we don't do that. Why? Because if we *already* have the timezone
information, it doesn't hurt to simply display it.

> As
> anyone who studied static knows, if you provide too many resting
> points you obtain instability.

What does that even mean? date.strftime("%s %z") *already* returns the
timezone, and there's no instability.

> I share Tadayoshi-san's conclusions.

And what are those conclusions?

Let me ask the question more pointedly to you.

We *already* present the timezone when we do DateTime.strftime("%s
%z"), because it doesn't hurt. And DateTime.strptime() is the converse
of DateTime.stftime(), and the timezone in is the string, and the
timezone is specified in the format, and we have a field to store the
timezone. So, how could it possibly hurt to simply parse the damn
timezone and store it?
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-04 08:48
(Received via mailing list)
On Sun, May 4, 2014 at 1:38 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> timezone is specified in the format, and we have a field to store the
> timezone. So, how could it possibly hurt to simply parse the damn
> timezone and store it?

Also. Let's suppose that you are right and in "%s %z" the timezone
should be ignored.

Does that mean we need to revert the change in Time.strptime()?
(because it's *already* parsing the timezone)

And does that mean that we should fix Date.strftime() as well so that
it ignores the timezone? (because it's *already* presenting it
correctly)

As things are right now Time.strptime() behaves differently than
DateTime.strptime(), and DateTime.strftime() behaved differently than
DateTime.strptime(). It's totally inconsistent.
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-04 11:24
(Received via mailing list)
On Sun, May 4, 2014 at 1:38 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:

> We *already* present the timezone when we do DateTime.strftime("%s
> %z"), because it doesn't hurt. And DateTime.strptime() is the converse
> of DateTime.stftime(), and the timezone in is the string, and the
> timezone is specified in the format, and we have a field to store the
> timezone. So, how could it possibly hurt to simply parse the damn
> timezone and store it?

Actually let me clarify that. We are *already* parsing the timezone,
and we are *already* storing it. But later on the code is dropping it,
so all we have to do is not drop the timezone.
D9d7afc2a6bd87c96532f91da29553f1?d=identicon&s=25 Sascha Abel (daemor)
on 2014-05-04 13:27
Felipe Contreras wrote in post #1144885:
>
>> If you provide both %s and %z, you provide *too much* information.
>
> But we already have that information!
>
> Here, I'll put it yet one more time:
>
>   DateTime.parse("1970-01-01 01:00 +0100").strftime("%s %z")
>   => "0 +0100"
>
> If we follow your rationale, that should return "0 +0000", or maybe even
> fail.
>
> But we don't do that. Why? Because if we *already* have the timezone
> information, it doesn't hurt to simply display it.
>

I don't think this is what happens at all. If you do

  t = DateTime.parse("1970-01-01 01:00 +0100")

you'll get a DateTime object complete with timezone because that is what
parse does. But if you

  t.strftime('%s %z')

you do not get some sort of "timestring". What you actually do is ask to
build a string in the following manner:

  '%s %z' => '0' + ' ' + '+0100'


And now that i think about it:

From https://bugs.ruby-lang.org/issues/9794
>Time.strptime() works correctly:
>
>  Time.strptime('0 +0100', '%s %z').strftime('%s %z')
>  => "0 +0100"

It indeed works perfectly fine, just not the way you think:

  Time.strptime('0 +0200', '%s %z').strftime('%s %z')
  => "0 +0100"

You ask Time to infer a time from a string and give it *hints* as to how
to interpret what it finds. But since you say the first thing in your
string should be the number of seconds since epoch ('%s') it stops right
there at the first space. It already has sufficient data do infer a
time,
no need for a timezone. Number of seconds ist just that, a number.

I guess that all Time and DateTime objects do get a timezone by default
so the local timezone is assigned and gets printed if you ask strftime
to
do so.

Cordially,

daemor
D9d7afc2a6bd87c96532f91da29553f1?d=identicon&s=25 Sascha Abel (daemor)
on 2014-05-04 19:45
(Received via mailing list)
Felipe Contreras wrote in post #1144885:
> If we follow your rationale, that should return "0 +0000", or maybe even
> fail.
>
> But we don't do that. Why? Because if we *already* have the timezone
> information, it doesn't hurt to simply display it.
>

I don't think this is what happens at all. If you do

   t = DateTime.parse("1970-01-01 01:00 +0100")

you'll get a DateTime object complete with timezone because that is what
parse does. But if you

   t.strftime('%s %z')

you do not get some sort of "timestring". What you actually do is ask to
build a string in the following manner:

   '%s %z' => '0' + ' ' + '+0100'


And now that i think about it:

Fromhttps://bugs.ruby-lang.org/issues/9794
>Time.strptime() works correctly:
>
>  Time.strptime('0 +0100', '%s %z').strftime('%s %z')
>  => "0 +0100"

It indeed works perfectly fine, just not the way you think:

   Time.strptime('0 +0200', '%s %z').strftime('%s %z')
   => "0 +0100"

You ask Time to infer a time from a string and give it *hints* as to how
to interpret what it finds. But since you say the first thing in your
string should be the number of seconds since epoch ('%s') it stops right
there at the first space. It already has sufficient data do infer a
time so the timezone in the string never gets parsed.
But I guess that all Time and DateTime objects do get a timezone by
default
so the local timezone is assigned and gets printed if you ask strftime
to do so.

Cordially,

daemor
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-04 22:03
(Received via mailing list)
On Sun, May 4, 2014 at 12:39 PM, Sascha Abel <sascha.abel@ewetel.net>
wrote:

> But if you
>
>   t.strftime('%s %z')
>
> you do not get some sort of "timestring". What you actually do is ask to
> build a string in the following manner:
>
>   '%s %z' => '0' + ' ' + '+0100'

Yes, but that's an implementation detail. If "%s %z" was truly wrong,
the fact that it returns the stored timezone could be considered a
bug.

> It indeed works perfectly fine, just not the way you think:
>
>   Time.strptime('0 +0200', '%s %z').strftime('%s %z')
>   => "0 +0100"

Huh?

  require 'time'
  Time.strptime('0 +0200', '%s %z').strftime('%s %z')
  => "0 +0200"
  RUBY_VERSION
  => "2.2.0"

What version are you using?
C993c6aaffc6cf7b477a5075099e1d36?d=identicon&s=25 Peter Hickman (Guest)
on 2014-05-04 23:15
(Received via mailing list)
>
> > It indeed works perfectly fine, just not the way you think:
> >
> >   Time.strptime('0 +0200', '%s %z').strftime('%s %z')
> >   => "0 +0100"
>


For what it's worth the values I get for:

Time.strptime('0 +0200', '%s %z').strftime('%s %z')

are

"0 +0200" for "2.0.0"

"0 +0100" for "1.9.3"

"1399234482 +0100" for "1.9.2"
A26503af74973ec9b596e540d27df383?d=identicon&s=25 __ tiredpixel (tiredpixel)
on 2014-05-04 23:39
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/2014 22:15, Peter Hickman wrote:
> are
>
> "0 +0200" for "2.0.0"
>
> "0 +0100" for "1.9.3"
>
> "1399234482 +0100" for "1.9.2"
>

I haven't looked as far back as 1.9.2, but for

    require 'time'
    Time.strptime('0 +0200', '%s %z').strftime('%s %z')

I appear to be getting results which vary across versions:

VERSION       RESULT
1.9.3-p125    0 +0100
1.9.3-p194    0 +0100
1.9.3-p286    0 +0100
1.9.3-p327    0 +0100
1.9.3-p362    0 +0100
1.9.3-p374    0 +0100
1.9.3-p385    0 +0100
1.9.3-p392    0 +0100
1.9.3-p429    0 +0100
1.9.3-p448    0 +0100
1.9.3-p484    0 +0200
1.9.3-p545    0 +0200
1.9.3-dev     0 +0200
2.0.0-p0      0 +0100
2.0.0-p195    0 +0100
2.0.0-p247    0 +0100
2.0.0-p353    0 +0200
2.0.0-p451    0 +0200
2.0.0-dev     0 +0200
2.1.0-rc1     0 +0200
2.1.0         0 +0200
2.1.1         0 +0200
2.2.0-dev     0 +0200

But perhaps I am somehow mistaken in my test...

Peace,
tiredpixel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTZrOLAAoJEF84Eew71SD2facIAMHOK/wkAaVyaWTxrZlfs9jZ
fBSq/3wFiSskychOSsv855qOShBk0fULB5pGi6ZuYSI1kuP2BHEgL1NaW4hIEhLq
95Kg0n+uMAbKK/vQU48Gi9Kp7lMyoXkjtmizP/bNMsHRUepJD5EeStHLI4trl7nO
txrQlq0Xs2OjqN04a5+djUKQ9+BzOdxoMhID9zJOZwsL3XeBb34HFkK45TBZdMw8
DPg24kZX9/iZX/JSw6gnwz7e+PjAa7IYRyXMRz18sEuD+DyjyEjU0yJl7G8AyTSC
I9e0JXGlTq195rwISSH04Y4yzIy6BIRtnTqukjUQZHCfk8Ua8Onr7rB2D6ZtQwU=
=TUtF
-----END PGP SIGNATURE-----
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-05 00:00
(Received via mailing list)
On Sun, May 4, 2014 at 4:39 PM, tiredpixel <tp@tiredpixel.com> wrote:
> On 04/05/2014 22:15, Peter Hickman wrote:

> 1.9.3-p392    0 +0100
> 2.0.0-dev     0 +0200
> 2.1.0-rc1     0 +0200
> 2.1.0         0 +0200
> 2.1.1         0 +0200
> 2.2.0-dev     0 +0200
>
> But perhaps I am somehow mistaken in my test...

That's correct.

The fix was introduced in 2.1.0:

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=r...

And backported since 1.9.3-p484

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=r...
D9d7afc2a6bd87c96532f91da29553f1?d=identicon&s=25 Sascha Abel (daemor)
on 2014-05-05 00:52
(Received via mailing list)
Am 04.05.2014 22:03, schrieb Felipe Contreras:
>
> On Sun, May 4, 2014 at 12:39 PM, Sascha Abel
> <sascha.abel@ewetel.net>wrote:
>>
>> But if you t.strftime('%s %z') you do not get some sort of
>> "timestring". What you actually do is ask to build a string in the
>> following manner: '%s %z' => '0' + ' ' + '+0100'
>
> Yes, but that's an implementation detail. If "%s %z" was truly wrong,
> the fact that it returns the stored timezone could be considered a bug.

I don't think it's an implementation detail, it is intentional so that
(Date)Time.strftime may accommodate to every format that may or may not
exist today.
But what i really want to say is this: '%s %z' seemsnonsensical to me,
simply because the timezone doesn't add any information. The number of
seconds since epoch is sufficient to fix a point in time.

t1= DateTime.strptime('3600 +0000', '%s %z')
t2 = DateTime.strptime('3600 +0200', '%s %z')

Both t1 and t2 are pointing at one hour after epoch regardless of any
timezone. '%s' and '%z' are completely independent from one another.
They don't make sense together. It is as saying "It's seven o'clock MET
and here you have some timezone".

>> It indeed works perfectly fine, just not the way you think:
>> Time.strptime('0 +0200', '%s %z').strftime('%s %z') => "0 +0100"
>
> Huh? require 'time' Time.strptime('0 +0200', '%s %z').strftime('%s
> %z') => "0 +0200" RUBY_VERSION => "2.2.0" What version are you using?

Oops, my bad, i was actually on 2.0.0p247 when i tried that.
So they did change the behaviour of Time.strptime. While i really see no
sense in '%s %z' i don't like the inconsistency of Time and DateTime
either. And if git is using this then maybe Ruby should support it
simply out of pragmatism. But in the end i see no bug, and so it'd be
really up to us to *persuade* the maintainer of this code.

Have a good night,

daemor
F0987c97234fa9c6b26f796bdbdab037?d=identicon&s=25 Andrew Vit (Guest)
on 2014-05-05 01:30
(Received via mailing list)
On 14-05-04, 15:51, Sascha Abel wrote:
> The number of seconds since epoch is sufficient to fix a point in time.

Yes, but the offset adds important information, or else we would be
doing everything in UTC. (I wish for that perfect world.)

If you compare time 0 in Japan (+9) and time 0 in Hawaii (-10), they are
different dates. Without a zone, `strptime('0', '%s')` assumes your
local zone. (In my locale, the date for time 0 was 1969-12-31.)

I may want to ask "What was the date for time 0 in Japan?":

     Time.strptime('0 JST', '%s %z').day == 1      # true
     DateTime.strptime('0 JST', '%s %z').day == 1  # true

Looks good. Now "What was the date for time 0 in Hawaii?":

     Time.strptime('0 HST', '%s %z').day == 31      # true
     DateTime.strptime('0 HST', '%s %z').day == 31  # false!!!

The answer for DateTime is wrong because it's not using all the
information given.

The difference between parsing '%F %T %z' and '%s %z' is:

For '1970-01-01 00:00:00 +0100' the offset is needed to *interpret* the
time.

For '0 +0100' the offset is needed to *represent* the time.

PS, can we please change the subject of this thread if we're discussing
the bug and not the community/process?

Andrew Vit
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-05 03:03
(Received via mailing list)
On Sun, May 4, 2014 at 6:29 PM, Andrew Vit <andrew@avit.ca> wrote:
> On 14-05-04, 15:51, Sascha Abel wrote:
>>
>> The number of seconds since epoch is sufficient to fix a point in time.
>
> Yes, but the offset adds important information, or else we would be doing
> everything in UTC. (I wish for that perfect world.)

Exactly.

A date like "1970-01-01 01:00 +0100" *needs* the timezone in order to
be interpreted correctly, however it contains both date-time and zone.
A date like "0 +0100" doesn't "need" the timezone to be interpreted,
but also contains both.

You provided a very good example of why that's desirable, but here's
another I expect to work:

  orig = "1970-01-01 01:00:00 +0100"
  gitdate = DateTime.parse(orig).strftime("%s %z")
  new = DateTime.strptime(gitdate, '%s %z').strftime('%F %T %z')
  new == orig
  => true

Would you expect otherwise?

> PS, can we please change the subject of this thread if we're discussing the
> bug and not the community/process?

Normally I would, but it seems Tadayoshi has seen the light :)

https://bugs.ruby-lang.org/projects/ruby-trunk/rep...
B5c20f697f141bfc00b1b57e581101c9?d=identicon&s=25 Benjamin F. (benjamin_f)
on 2014-05-05 05:09
(with new, less angry subject)

Felipe Contreras wrote in post #1144960:

> Normally I would, but it seems Tadayoshi has seen the light :)
>
> https://bugs.ruby-lang.org/projects/ruby-trunk/rep...

I don't know how much of this thread is a result of faceless electronic
collaboration. I know I've been frustrated plenty of times when
collaborating on open source code that someone else owns. I've also been
frustrated by some feature requests to projects I maintain.  I've never
found it helpful to take the discussion from arguments on the merits to
emotion.  That's not about how I fee;. it's just strategy.  A lot of
these emails probably should have stayed in the 'Draft' box overnight.

For example, I was looking at the code for unrelated reasons and rather
quickly found that Tadayoshi Funaba wrote and maintained this library
since 1998.  So, right or wrong, he clearly has ownership of the code.
That alone should have suggested a different approach.

https://github.com/ruby/ruby/blob/v1_8_7_374/lib/date.rb#L4


# Author: Tadayoshi Funaba 1998-2010
#
# Documentation: William Webber <william@williamwebber.com>

https://github.com/ruby/ruby/blob/trunk/ext/date/d...

# date_core.c: Coded by Tadayoshi Funaba 2010-2014
161289732b5b8c9dcb5834a3f0535340?d=identicon&s=25 Chad Perrin (Guest)
on 2014-05-05 18:17
(Received via mailing list)
On Fri, May 02, 2014 at 03:57:15PM -0700, Eric Hodel wrote:
> that time.  I have personally felt these feelings of frustration
> I really don???t want to fix bugs for people that say such things and
> don???t want to welcome them into my community.

I suspect it is more a matter of no tact and no shying away from saying
things in a way that might be construed as racist rather than actually
racist.  Notice that:

1. He refers to the problem as a Japanese cultural issue because,
apparently, he has been told that the way things are managed is a choice
specifically grounded in Japanese culture -- not (as far as I can tell)
because he thinks Japanese people are incapable of doing better due to
some racial constraint.

2. He refers to a perceived need to communicate in English as a "lingua
franca" of international open source software development, despite the
fact his own name suggests to me that perhaps English is not his native
language.  This suggests to me that he is probably speaking of a "de
facto standard" language for communication, as he perceives things,
rather than xenophobic linguistic imperialism or something like that.

I agree that the correct response should have been to ask someone for
translation assistance and perhaps suggest that the maintainer in
question should ensure that he can respond in English to people who
communicate with him in English in his capacity as a maintainer, even if
that means co-ordinating such responses with someone else who knows
English well.  I do not agree that we should have hair-triggers when it
comes to resorting to accusations of actual racism.

If he *is* being genuinely racist, I don't know that I have any
objections to asking him to leave the Ruby community (though that is not
necessarily the same thing as asking him to stop using Ruby).  I just
don't think the evidence necessarily indicates genuine racism.  It only
indicates a huge attitude problem, in my estimation.
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-05 20:36
(Received via mailing list)
On Mon, May 5, 2014 at 11:16 AM, Chad Perrin <code@apotheon.net> wrote:

> 1. He refers to the problem as a Japanese cultural issue because,
> apparently, he has been told that the way things are managed is a choice
> specifically grounded in Japanese culture -- not (as far as I can tell)
> because he thinks Japanese people are incapable of doing better due to
> some racial constraint.

That's right. I know very capable Japanese programmers, and I know no
race could be impeded in anyway from being good programmers.

> 2. He refers to a perceived need to communicate in English as a "lingua
> franca" of international open source software development, despite the
> fact his own name suggests to me that perhaps English is not his native
> language.  This suggests to me that he is probably speaking of a "de
> facto standard" language for communication, as he perceives things,
> rather than xenophobic linguistic imperialism or something like that.

Right again. My first language is Spanish, I had to learn English like
the vast majority of the people in the world that want to engage in
international communities.

The problem is not the race, the problem is the culture (which is not
specific to any race).

In this particular case reason triumphed, so that's good, but I feel
the issue shouldn't have happened in the first place, which suggest
some deeper issue. Hopefully issues like this don't happen again, but
if they do, well, we'd know the answer.

Cheers.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (robert_k78)
on 2014-05-06 14:46
(Received via mailing list)
On Mon, May 5, 2014 at 8:36 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:

> The problem is not the race, the problem is the culture (which is not
> specific to any race).

But who decides which is the "right" culture that we should adhere to?
 Do we automatically inherit it with the language English?

> In this particular case reason triumphed, so that's good, but I feel
> the issue shouldn't have happened in the first place, which suggest
> some deeper issue. Hopefully issues like this don't happen again, but
> if they do, well, we'd know the answer.

Even if the original issue should not have come up I - as a bystander
in this case - also feel that your reaction should not have happened.
There are ways to air frustration and even anger without resorting to
four letter terms or name calling. In my experience a different style
of communication is much more helpful in resolving conflicts and
reaching goals. Another effect of some styles of communication is that
people might start wondering whether it is really that important to
the person to get her problem resolved.

Kind regards

robert
2cddfa1d5e719e79aeab4e351c1793e9?d=identicon&s=25 Alex Chaffee (alexch)
on 2014-05-06 15:47
(Received via mailing list)
On Sun, May 4, 2014 at 7:29 PM, Andrew Vit <andrew@avit.ca> wrote:
> Yes, but the offset adds important information, or else we would be doing
> everything in UTC. (I wish for that perfect world.)

This.

As far as I can tell, Felipe's concerns are completely justified, his
patch is technically correct, and his bug was prematurely closed
without the discussion which we are now having -- and would not be
having if he had not brought it to the attention of this list, however
rudely.

In my experience, using Ruby's chaotic Date/Time/DateTime/TimeWithZone
interface is no fun at all, and leads to bugs and misunderstandings in
any international app (which most web apps are, since the server is
usually in UTC and the clients are worldwide).

(FWIW, JavaScript is worse, since a JavaScript Date object has no time
zone info at all, so only "local" and "UTC" are possible without
3rd-party libraries.)

(And yes, I know TimeWithZone is ActiveSupport, which makes my point:
if the stdlib worked well, there would be no need for Rails to extend
it.)

 - A
D2bff075522befb15313dab85f3a671b?d=identicon&s=25 Kevin Walzer (codebykevin)
on 2014-05-06 16:04
(Received via mailing list)
On 5/6/14, 9:46 AM, Alex Chaffee wrote:
> As far as I can tell, Felipe's concerns are completely justified, his
> patch is technically correct, and his bug was prematurely closed
> without the discussion which we are now having -- and would not be
> having if he had not brought it to the attention of this list, however
> rudely.

He could have made his case without behaving like an ass. I hope the
patch was accepted in spite of and not because of his behavior.

--Kevin
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-06 21:15
(Received via mailing list)
On Tue, May 6, 2014 at 7:46 AM, Robert Klemme
<shortcutter@googlemail.com> wrote:
> On Mon, May 5, 2014 at 8:36 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>
>> The problem is not the race, the problem is the culture (which is not
>> specific to any race).
>
> But who decides which is the "right" culture that we should adhere to?

I think "code talks, bullshit walks" is a good start.

>> In this particular case reason triumphed, so that's good, but I feel
>> the issue shouldn't have happened in the first place, which suggest
>> some deeper issue. Hopefully issues like this don't happen again, but
>> if they do, well, we'd know the answer.
>
> Even if the original issue should not have come up I - as a bystander
> in this case - also feel that your reaction should not have happened.

Yeah, but you cannot control the reactions of other people.

What you can do is make sure problematic people don't end up
maintaining core parts of Ruby.
1bb1c1a41b92d9f18e2890c3f6d33970?d=identicon&s=25 Felipe Contreras (Guest)
on 2014-05-06 21:16
(Received via mailing list)
On Tue, May 6, 2014 at 9:03 AM, Kevin Walzer <kw@codebykevin.com> wrote:
> On 5/6/14, 9:46 AM, Alex Chaffee wrote:
>>
>> As far as I can tell, Felipe's concerns are completely justified, his
>> patch is technically correct, and his bug was prematurely closed
>> without the discussion which we are now having -- and would not be
>> having if he had not brought it to the attention of this list, however
>> rudely.
>
> He could have made his case without behaving like an ass. I hope the patch
> was accepted in spite of and not because of his behavior.

If the patch is technically correct and benefits Ruby, it should be
applied, period. It doesn't matter who sent it, how, or for what
reasons.
F0987c97234fa9c6b26f796bdbdab037?d=identicon&s=25 Andrew Vit (Guest)
on 2014-05-06 21:27
(Received via mailing list)
On 14-05-06, 12:16, Felipe Contreras wrote:
> If the patch is technically correct and benefits Ruby, it should be
> applied, period. It doesn't matter who sent it, how, or for what
> reasons.

I think that's generally how it works already. In this case there was
obviously a disagreement or misunderstanding.

I'm not clear on Tadayoshi-san's reasoning for rejecting the patch
either and I don't think you were wrong to expect a response in your
language of choice. Ruby is international, and I think we can try to do
that on request.

If anyone is willing to put a summary in English I would appreciate
reading it. I work with Time and Date a lot, but not DateTime so I'm not
sure if it's meant to be different in some ways.

Andrew Vit
43421679c356f438c69bf6947e62c4ec?d=identicon&s=25 Tsuyoshi S. (tsuyoshi_s)
on 2014-07-16 23:22
I am just one among the many Ruby users in the world, appreciating (most
of the) Ruby developers, am a native Japanese speaker, but I
totally agree with Felipe Contreras regarding his points regarding
Tadayoshi Funaba. I have not read through the particular issue Felipe
Contreras mentions, but a different issue came to my attention.

In this issue https://bugs.ruby-lang.org/issues/8941, the poster reports
that %Y accepts digits less than four, where the document clearly says
it has to be at least four digits. This is not a matter of opinion; it
is clearly a contradiction: either the Ruby time implementation is
wrong, or the documentation is wrong. By comparison with other
standards/languages including Python, the poster assumed the
documentation is correct and %Y should not accept digits less than four.
And he mentioned that Python accepts only four digits. This is a very
constructive bug report.

However, against this bug report, Tadayoshi Funaba responded with: "we
don't need any bug reports for python." How can Tadayoshi Funaba write
something like that? What kind of attitude is that? On top of that,
Tadayoshi Funaba changed the category to joke, and closed the issue.
That is extremely rude. Surely not what a professional programmer would
do. As far as I see, the poster of that issue hadn't made a complaint
like Felipe Contreras did, but must have come to feel the same as him. I
am concerned that the
poster might not want to make a bug report any more. I made a new
issue (https://bugs.ruby-lang.org/issues/10049) in hope to resolve the
contradiction between Ruby and RDoc.

I agree with Felipe Contreras that Ruby is extremely awesome, and just
as he is, I am concerned that this kind of response is having a negative
effect against Ruby's worldwide success.
5c4e55b92169c16ce2ca8fd75318eded?d=identicon&s=25 David Unric (dunric)
on 2014-07-17 16:05
@Felipe Contreras
  Most arguments to the topic were already expressed by others. All I
can add your argumentation with bandwagon fallacy (glibc, perl,
rubinius), false authority (link to your pitiful contributions) or even
link to unrelated TIOBE index are absolutely ridiculous.

  I'm not against discussing the topic from all points of view, but your
persistence on accepting your proposal is just childish. Your time and
effort invested make no claims to be accepted, it was just your
decision.
I hope somebody you trust (family, friends) will help you with your
personality disorder as it becomes dangerous to grow up with this
untreated …
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.