On Sat, May 3, 2014 at 9:27 AM, Yukihiro Matsumoto <matz / ruby.or.jp> wrote:

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

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

-- 
Felipe Contreras