Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Tuesday September 16, 2008
03:44 PM

How Not To Be A Jackass: Replying to offers of help

[ #37465 ]

Some of you may know libtai, djb's 2038-safe date and time library. When I started looking at 2038 fixes for Perl this was one of the first things I looked at.

Unfortunately, it doesn't handle time zones so I went and wrote my own. Just recently I thought, "hey, maybe libtai could make use of my technique to use a 32 bit localtime() to do time zone calculations!" So I posted a message to the libtai mailing list...

Subject:  Algorithm to exploit 32 bit time functions to do time zone calculations
 
Hi,
I'm writing to you in reference to your libtai library whose TODO file states
that "support time zones" is still todo.  I had originally considered using
libtai in Perl to avoid the Unix 2038 bug, but Perl requires time zone support.
 
Instead, I am rewriting the time.h library functions to be 2038-clean.  The
effort is located here.
http://code.google.com/p/y2038/
 
The piece which is of interest to libtai is this:
http://code.google.com/p/y2038/wiki/HowItWorks
 
I have figured out a way to make use of 32 bit system functions to do 64 bit
time zone and daylight savings calculations.  I thought you might be able to
apply this to libtai.
 
Thanks,
Schwern
 
PS  Any potential license issues I'm happy to work out.

Today I got a reply back.

From: NAME WITHHELD <foo@bar.com>
To: Michael G Schwern <schwern@pobox.com>
Subject: Re: Algorithm to exploit 32 bit time functions to do time zone
  calculations
 
Michael G Schwern dixit:
 
>Instead, I am rewriting the time.h library functions to be 2038-clean.  The
 
*yawn* MirBSD uses a 64-bit time_t type on i386 (ILP32), with the aid
of tm2mjd and mjd2tm functions from DJB libtai code. The rest of the
functions from the time library work just fine
 
>PS  Any potential license issues I'm happy to work out.
 
libtai is in the Public Domain.

Essentially, "your shit is boring, we've already got it all figured out, would you like a copy of our wonderful software?". Any desire I had to help has now been replaced by indignant rage. The reply is not so much a response to my offer for help, but a way to show how superior libtai and MirBSD are.

And it's not like this is even a busy mailing list.

Note that this was just one reply from one guy. I don't even know if he's associated with the project or just some jackass on the list. Either way, he's nearly lost them a potential developer.

How could this instead have gone down? It's an amazingly small change. Watch.

From: NAME WITHHELD <foo@bar.com>
To: Michael G Schwern <schwern@pobox.com>
Subject: Re: Algorithm to exploit 32 bit time functions to do time zone
  calculations
 
Michael G Schwern dixit:
 
>Instead, I am rewriting the time.h library functions to be 2038-clean.  The
 
You might be reproducing work.
 
MirBSD uses a 64-bit time_t type on i386 (ILP32), with the aid
of tm2mjd and mjd2tm functions from DJB libtai code. The rest of the
functions from the time library work just fine.
 
>PS  Any potential license issues I'm happy to work out.
 
libtai is in the Public Domain so you can make use of it in your project
like MirBSD does.

That reads so much better, but so little changed.

The judgmental "yawn" is removed. In it's place is concern that I might be reproducing the wheel (which I might). In that light, mentioning MirBSD is a helpful example and, with the clarification, so is bringing up the license.

So little effort to add so much tact.

I decided not to let it drop. To call him out, in public and on list. It might be tilting at windmills, but when someone's being a jackass somebody's got to call them on it. It's hard to do constructively when you're pissed.

From: Michael G Schwern <schwern@pobox.com>
To: NAME WITHHELD <foo@bar.com>
CC: libtai@list.cr.yp.to
Subject: Re: Algorithm to exploit 32 bit time functions to do time zone calculations
 
Thorsten Glaser wrote:
> Michael G Schwern dixit:
>
>> Instead, I am rewriting the time.h library functions to be 2038-clean.  The
>
> *yawn*
 
Me:  "Hey, I have this great idea that might help out!"
You: "Your shit is boring."
 
This is the sort of reply one gets when offering help?  What a jackass.
 
> MirBSD uses a 64-bit time_t type on i386 (ILP32), with the aid
> of tm2mjd and mjd2tm functions from DJB libtai code. The rest of the
> functions from the time library work just fine&#8230;
 
If I understand correctly, that's an entire operating system.
 
The target for y2038 is people writing portable applications which don't have
the luxury of waiting for every OS to upgrade to a 64 bit time_t.  It works
with a 32 bit time_t and it handles time zones.
 
This is something, as I understand it, that libtai does not do (this is the
impression I get, please correct me if I'm wrong) and I'm offering a way that
it could.
 
Also you might want to have a look at the tests in y2038.  libtai's INSTALL
says it's not very well tested and what it has appears to be manual.  y2038
has automated tests with extensive testing data files for expected gmtime()
and localtime() results.  You might be able to adapt that data and also the
tap.c test library to make writing tests easy.
 
Or is that too boring?

*UPDATE*

He apologized, said he only wanted to convey that I was repeating work. I said I was sorry for getting off on the wrong foot. Now that's done we're getting some useful discussion done. Better than me just walking off in a huff.

*UPDATE 2*

The guy's actually turned out to be quiet nice and it's good to have someone else to have obscure calendaring rants with.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • > To call him out, in public and on list. It might be tilting at windmills, but when someone's being a jackass somebody's got to call them on it.

    Schwern, you're being a jackass.

    • I am hoping that was being sarcastic.

      • No. He's over-interpreting and escalating a blunt but straight forward answer.

        And he's exhibiting exactly the traits he doesn't like.

        Similarly, I'm a jackass as well.

        • Jackassery has to be called out, without feedback no corrective action can happen.

          There is a vast difference between saying "Hey, you're being a jerk!" and being a jerk. Now, it might have been more tactful to do it in private, but doing it in public puts everyone else on notice: this behavior will not be tolerated!

          It all worked out in the end. He apologized and clarified that he meant "it's been done already". I thanked him and said I'm sorry we got off on the wrong foot. He gave a little, I gave a li

          • It all worked out in the end. He apologized and clarified that he meant "it's been done already". I thanked him and said I'm sorry we got off on the wrong foot. He gave a little, I gave a little. Now that's done and we're talking about productive things.

            Passive/aggressive FTW!!1!

            Seriously though, what you did was fine. In public if you want to make a point you have to match the response to the tone of the argument, as long as the tone isn't too far gone.

            In real life I don't tend to pick up or display body

            • ...but it wasn't passive/aggressive. Passive/aggressive would have been to not respond to him and just go post about it on my blog and be angry and feel justified and never find out if it was just a case of poor wording. Passive/aggressive avoids conflict (and thus resolution). Passive/aggressive is quicker, easier, more seductive. The dark side it is.