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

Ruby
41

On Sun, May 4, 2014 at 1:19 AM, Carlo E. Prelz [email protected] 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?

42

On Sun, May 4, 2014 at 1:38 AM, Felipe C.
[email protected] 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.

43

Felipe C. 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 Feature #9794: DateTime.strptime() doesn't work correctly for '%s %z' - Ruby master - Ruby Issue Tracking System

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

44

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

45

On Sun, May 4, 2014 at 12:39 PM, Sascha A. [email protected]
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?

46

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/2014 22:15, Peter H. 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-----

47

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”

48

On Sun, May 4, 2014 at 4:39 PM, tiredpixel [email protected] wrote:

On 04/05/2014 22:15, Peter H. 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=revision&revision=43177

And backported since 1.9.3-p484

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=43483

49

On 14-05-04, 15:51, Sascha A. 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 V.

50

Am 04.05.2014 22:03, schrieb Felipe C.:

On Sun, May 4, 2014 at 12:39 PM, Sascha A.
[email protected]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

51

On Sun, May 4, 2014 at 6:29 PM, Andrew V. [email protected] wrote:

On 14-05-04, 15:51, Sascha A. 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 :slight_smile:

https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/45822

52

(with new, less angry subject)

Felipe C. wrote in post #1144960:

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

https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/45822

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

Author: Tadayoshi F. 1998-2010

Documentation: William W. [email protected]

https://github.com/ruby/ruby/blob/trunk/ext/date/date_core.c#L2

date_core.c: Coded by Tadayoshi F. 2010-2014

53

On Mon, May 5, 2014 at 11:16 AM, Chad P. [email protected] 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.

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

54

On Fri, May 02, 2014 at 03:57:15PM -0700, Eric H. 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.

55

On Sun, May 4, 2014 at 7:29 PM, Andrew V. [email protected] 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
56

On 5/6/14, 9:46 AM, Alex C. 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

57

On Mon, May 5, 2014 at 8:36 PM, Felipe C.
[email protected] 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

58

On Tue, May 6, 2014 at 9:03 AM, Kevin W. [email protected] wrote:

On 5/6/14, 9:46 AM, Alex C. 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.

59

On 14-05-06, 12:16, Felipe C. 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 V.

60

On Tue, May 6, 2014 at 7:46 AM, Robert K.
[email protected] wrote:

On Mon, May 5, 2014 at 8:36 PM, Felipe C.
[email protected] 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.