Your tone doesn't make you wrong, but it doesn't make you an ambassador either. You could have chosen much less combative words, which would have avoided pushing him into a defensive posture, and avoided most of the discussion. It's pretty obvious looking at the exchange that he was confused about what you were talking about, why it was a problem, and why it should be fixed.
A diatribe about the Japanese language and culture reflects poorly upon you. Every culture has their way of writing and expression and norms, and we give leeway to people speaking a foreign language for that reason.
Like it or not, we're all human, and one of the greatest skills one can learn is the skill of de-escalation.
Yes, every culture has their idiosyncrasies, which is precisely the reason why mentioned them. If every culture is different, then different cultures... are *different*. Being aware of the differences helps understand where the potential frictions might be.
You are making assumptions about me, but what about Tanaka and Matsumoto? They are Japanese and they couldn't get Funaba to understand either.
Ultimately Funaba wasn't angry with me, he just ignored me, he was angry with Matsumoto for listening to me and telling him what to do. Could Matsumoto have picked "less combative words"?
Or is it possible that there was a problem with Funaba?
I've dealt with Japanese people for a long time, and what I'm seeing here is people trying to avoid a person who is being disruptive and rude. And I'd be miffed too, because your writing style comes off as arrogant and entitled.
I don't mean to imply that this is how you are in person, and I'm sorry that this will come off as an attack, but business communication is something that you'll really need to work on if you want to successfully contribute to larger projects (this is nothing to be ashamed of; Linus Torvalds had to take lessons, too). I'd also remove that blog post if I were you.
You yourself are hypocritically writing in a direct, laconic style while advising Felipe to politely tip toe around sensitivity issues. Why aren't you yourself trying to "empathize" with Felipe and whatever culture he's from?
To be clear, I obviously like direct communication. I'm just pointing out the hypocrisy of this comment chain.
> I have successfully contributed thousands of patches to many large projects. I don't need help.
Linus Torvalds successfully contributed far more, and for decades swore up and down that he didn't need any help with communicating (after all, what's so hard about it? You say what you mean and mean what you say! Child's play!). And yet even he eventually realized his need to learn.
At the end of the day, community and morale is far more important, because it improves velocity overall and fosters new blood. I know it's hard to see, because I've been there myself, scratching my head at why those "idiots" wouldn't just see reason and do things efficiently like me. Focusing on the code and not the people and their "silly" politics. I took far too long to realize that I was the problem.
He quotes three excerpts from an email exchange in Japanese followed by his "translation" where he leaves out much of the explanation and even the parts where they quote each other so he can demonstrate his claim that in Japanese "you have to say much more than just what is actually necessary."
Does that make it a fact? I don't think so, because I disagree that the explanations he cut out were actually unnecessary.
While I understand the point about displaying a time in a given timezone (output/strftime)
I don't see how specifying a timezone on a epoch count makes any sense (input/strptime).
A 'number of seconds since epoch' (%s) is a _duration_, not a time. It makes no sense to attach a time zone to it. (This seems to have been the initial response from the project maintainer).
From the original article the reported "bug" is about _parsing_ an epoch duration, not about displaying a time.
DateTime.strptime('0 +0100', '%s %z')
Probably I am missing something but I've re-read the original article and I cannot see this point addressed directly (examples are given but they have to do with displaying/output, not parsing).
You can argue that attaching a time zone to a `%s` doesn't make sense, but a lot of people do it, and more importantly: it doesn't hurt.
If you do `Time.strptime('0 +0100', '%s %z').to_i` you get the correct result: "0". That is: the number of seconds since the epoch is correctly parsed. The time zone is extra information that doesn't affect `%s` in any way. In other words: it's orthogonal.
Just because people say it doesn't mean it's true.
And the reason why I made the post is that there's an actual important issue with rubygems, but I'm not allowed to comment. Users are being negatively affected for no reason. I have the fixes.
Ask any user negatively affected by this and they would tell you I should be heard. In fact, I've received emails personally thanking me for persisting and trying to get it fixed.
This seemed to go beyond being blunt to get your point across.
It seems there were numerous possible better outcomes and I would have liked to see some acknowledgment of that in the conclusion, lessons learnt, instead of leaning on Linus and "I was right". Especially after 10 years reflection.
It does not look well for an outsider looking into Ruby maintenance to see a technical discussion devolve into a discussion about politeness and race. Luckily matz made the right call.
Felipe is right that:
1. `%s %z` is inconsistent in ruby.
2. He has consensus everywhere else.
3. Nobody has provided any good technical arguments against his.
Whether he is polite enough or not, code talks, bullshit walks.
The translations that were purposely cut from the post:
Chunk 1
Unlike the day of the week and the date, %s and %z are independent, so I don't see the problem.
> Here, independent means orthogonal, so changing one doesn't change the other.
It doesn't mean there is a problem, it just means they are different.
For example, it is possible to write a date in UTC and then change it to local time.
But this time it's only %s.
Suppose I am in Japan and dealing with UTC time.
Let's say I'm in Japan and I'm dealing with UTC time.
The given time is in UTC, but I'll refer to it as +09:00.
2001-02-03T04:05:06 UTC (+0900)
Since this is not common
DateTime.parse('2001-02-03T04:05:06').new_offset('+0900')
This is not common, so the description would be something like
Now, this kind of description is not currently in ruby, but I feel that what is required for the '%s %z' thing is something different from what we have been dealing with, which from my point of view includes this kind of thing.
Chunk 2
Perhaps if you could elaborate a bit more on what a date is or something like that, it might make it more understandable.
When I say date, I am including such time.
I think of this date as a kind of name assigned on a time axis based on certain rules. In space, it is like a milestone.
There are actually more imperfect dates, which are also dates.
Sometimes they can be identified by context and other information, and sometimes they can't.
Chunk 3
If you think the time difference has special significance, you can describe it in local time.
>
> The question is which local time, not the local time set by the OS, but an artificial local time with a > fixed difference from UTC.
> > I understand that you are talking about being able to record the given time difference as is.
> I understand that you are saying that the given time difference can be recorded as it is.
I'm not sure what you mean.
Since %s seems incomplete to begin with, I don't know why you are so hung up on it.
If we replace %s with space, we can't place milestones with it, it just shows the distance, and we can't define the distance, can we?
Also, just for the record, I would like to confirm that what Mr. Tanaka is referring to as fixed time difference is not universal.
The given self-evident local time is also useful, and the time zone = time zone information, not time difference.
It contains more information than just time difference.
Isn't it important to have the actual time system and format we are referring to, such as daylight saving time?
In that sense as well, I feel uncomfortable with the trend of %s bias.
Thank you for the translation, I've updated the blog post with them. I don't see any new actual information though. For example in chunk 2 what I gathered from Google Translate was:
> What I call a date includes time. It's like a name given on a point on the time axis.
And now it's:
> When I say date, I am including such time. I think of this date as a kind of name assigned on a time axis based on certain rules. In space, it is like a milestone. There are actually more imperfect dates, which are also dates. Sometimes they can be identified by context and other information, and sometimes they can't.
What information did we gain?
Anyway, in chunk 1 you said:
> Since this is not common DateTime.parse('2001-02-03T04:05:06').new_offset('+0900') This is not common, so the description would be something like
But that's not a correct sentence, I changed it to:
> Since this is not common, the description would be something like DateTime.parse('2001-02-03T04:05:06').new_offset('+0900').
Back in 2012 I encountered a bug that took me through many hoops to get fixed, all because of a single developer, which compelled me to start an infamous email thread.
A diatribe about the Japanese language and culture reflects poorly upon you. Every culture has their way of writing and expression and norms, and we give leeway to people speaking a foreign language for that reason.
Like it or not, we're all human, and one of the greatest skills one can learn is the skill of de-escalation.