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.
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.
Software is like 10% code, and 90% soft skills. You need to work on that.
https://felipec.wordpress.com/2011/09/23/no-gnome-doesnt-wan...
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).
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.
Like damn dude, you catch more flies with honey than vinegar. Don't they have a saying like that in Spain?
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.
There's more important things than tone.
> DateTime.parse('1970-01-01T01:00:00 +0100').strftime('%s %z') => "0 +0100"
Does that mean that "0 +0000" is the same as "0 +0100", "0 +0200", "0 +0300" etc.?
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.
> 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').
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.
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.
