[PATCH] convert svn with local timezone in revision dates

Greg Ward greg-hg at gerg.ca
Sat Mar 21 15:56:42 CDT 2009


On Sat, Mar 21, 2009 at 2:54 PM, Herbert Griebel <herbertg at gmx.at> wrote:
>> And: I suspect your patch is much more likely to be accepted if you
>> add some test code.
> Testing is not simple in that case because it would depend on
> the timezone. Don't know if a shell script can do this (would
> be glad if someone could provide this), if not, there would be
> a new py script for test.

Errr.  Oh yeah.  Of course.  Sometimes, I long for the good ol' days,
when a simple "TZ=-0400" was enough.

Hey!  Those days are still, sort of, with us:

  $ TZ=":Europe/Berlin" python -c "import time ; print time.timezone"
  -3600
  $ TZ=":America/Chicago" python -c "import time ; print time.timezone"
  21600

That works for me on Linux (Ubuntu 8.10) and Mac OS X (10.5).

Now, for an extra super sneaky trick, use a locale that is known not
to use daylight savings time, like the province of Saskatchewan: set
TZ=":Canada/Saskatchewan" and you should get the same TZ offset all
year long.  Until the provincial legislature changes their mind and
decides to synchronize with the rest of North America, of course.  ;-)

(Hey, I didn't say it was a *good* idea.)

> So my idea was to add an option that allows a customization
> py script. For example the user must specify
> a py script which is called in a context with special
> variables defined: author, message, date, ...

Sounds like a neat idea: basically plugins for conversion.  Hmmm.  I'm
sure you're not the only one who could use that.

> The code is executed in its own context and protected (necessary to prevent exploits).

This makes no sense.  Python no longer has a restricted mode, since it
was realized that it would take an army of security researchers to
keep it secure.  And what sort of exploit are you worried about: that
you'll write an evil plugin to sabotage your own conversion?

> If you give examples for the code, everybody can write his own code,
> even none programmers will have no troubles.

I also very much doubt that.  Even many professional programmers have
a hard time editing text files to get software to do what they want,
never mind writing code to customize it.  And as soon as you get
someone to write code and put it in a file, *poof* you've created a
new programmer.  Beware.

Greg


More information about the Mercurial-devel mailing list