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

[fcruxen]

On Sat, May 3, 2014 at 1:44 AM, John W Higgins [email protected]
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.

[fcruxen]

On Sat, May 3, 2014 at 12:16 AM, Felipe C. <
[email protected]> 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

[fcruxen]

On Sat, May 3, 2014 at 11:05 AM, John W Higgins [email protected]
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

[fcruxen]

Hello,

In message “Re: Who the f*heck is Tadayoshi F. and why can he reject
sensible patches unilaterally?”
on Sat, 3 May 2014 01:32:09 -0500, Felipe C.
[email protected] 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.

[fcruxen]

Subject: Re: Who the f*heck is Tadayoshi F. and why can he reject
sensible patches unilaterally?
Date: sab 03 mag 14 01:23:52 -0500

Quoting Felipe C. ([email protected]):

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

[fcruxen]

On Sat, May 3, 2014 at 9:27 AM, Yukihiro M. [email protected]
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 [email protected] 1398880902 -0700
-committer Junio C Hamano [email protected] 1398880902 -0700
+author Junio C Hamano [email protected] 1398880902 +0000
+committer Junio C Hamano [email protected] 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

[fcruxen]

On 5/3/14, 3:24 PM, Felipe C. 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

[fcruxen]

On Sat, May 3, 2014 at 3:05 PM, Kevin W. [email protected] wrote:

On 5/3/14, 3:24 PM, Felipe C. 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] Bus factor - Wikipedia

[fcruxen]

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 C.
<[email protected]

[fcruxen]

On Sat, May 3, 2014 at 1:36 PM, Carlo E. Prelz [email protected] 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.

[fcruxen]

On May 3, 2014, at 7:27, Yukihiro M. [email protected] 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?

[fcruxen]

On Sat, May 3, 2014 at 3:51 PM, Brandon W. [email protected]
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.

[fcruxen]

On 5/3/14, 4:33 PM, Felipe C. 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

[fcruxen]

On Sat, May 3, 2014 at 4:32 PM, Kevin W. [email protected] 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] What the Tech Industry Has Learned from Linus Torvalds: Jim Zemlin at TEDxConcordiaUPortland - YouTube
[2]
http://www.ilr.cornell.edu/directory/ja26531/downloads/Liberating_role_of_conflict_in_group_creativity.pdf

[fcruxen]

On 5/3/14, 6:16 PM, Felipe C. wrote:

On Sat, May 3, 2014 at 4:32 PM, Kevin W. [email protected] 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

[fcruxen]

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 N. and also Kouhei S. simply because someone keeping
ruby-gnome/gtk alive and healthy.

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

I reject the claim that Felipe C.'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.

[fcruxen]

On Sat, May 3, 2014 at 5:36 PM, Kevin W. [email protected] 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=&sort=commits_12_mo

[fcruxen]

On Sat, May 3, 2014 at 9:27 AM, Yukihiro M. [email protected]
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?

[fcruxen]

Subject: Re: Who the f*heck is Tadayoshi F. and why can he reject
sensible patches unilaterally?
Date: sab 03 mag 14 11:58:35 -0500

Quoting Felipe C. ([email protected]):

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

[fcruxen]

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