Ambiguous date handling

Hi,

I think this has come up before [1],[2] but we ran into this at $dayjob today. Our default MUA has an annoying habit of using a non RFC822 date format when saving an email as plaintext. This means the first 12 days of every month we run into the ambiguous date problem (our date convention is dd/mm/yy).

I see code in date.c for refusing a date in the future which would have caught this but it doesn't appear to be working for us.

Following this is a patch adding a testcase for this. With the following results:

  ok 1 - apply patch with ambiguous date
  not ok 2 - check ambiguous date # TODO known breakage
  ok 3 - apply patch with european date separator
  ok 4 - check european date
  # still have 1 known breakage(s)
  # passed all remaining 3 test(s)
  1..4

Thanks, Chris

-- [1] - http://thread.gmane.org/gmane.comp.version-control.git/18412/focus=18417 [2] - http://thread.gmane.org/gmane.comp.version-control.git/84512/focus=85735

-- This testcase is only good for the next couple of months. For a longer term test the current time would need to be set in the test setup.

---
 t/t4255-am-author-date.sh |   85 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)
 create mode 100755 t/t4255-am-author-date.sh

Chris Packham <judge.packham@gmail.com> writes:

The most sane thing to do when you know that your MUA *consistently* does dd/mm/yy (even though it may annoy you) is to massage its output before feeding it to Git. And it should be a very simple matter of a one-liner filter, no?

Regardless of the correctness of that "we reject timestamps way into the future" logic, it should be taken as the last resort. If you are on September 1st, both 9/12 and 12/9 will look like into the future for more than ten days (which is the cut-off, I think). If you are on December 28th, both look like sufficiently in the past.

On 09/12/2012 09:48 PM, Junio C Hamano wrote:

Consistent as long as you save as the default .txt. Some people have trained themselves to use the save as .eml option which uses RFC822 style output. sed 's|Date: (\d+)/(\d+)/(\d+)|\1.\2.\3|' should correct the former and ignore the latter. Could this be done in a applypatch-msg hook?

Duly noted. And I'm implying that the reject timestamps in future isn't actually working. I've just started looking at t0006-date.sh so see if I can prove it.

Chris Packham <judge.packham@gmail.com> writes:

Yuck.

Isn't the hook about fixing up the log message? Also I do not think the name of the original file is given to the hook, so there is no sufficient information to allow it to switch between two behaviours based on .txt or .eml.

But if you are massaging the _input_ to "git am", then you can certainly do the massaging even _before_ you feed it to "git am", no?

We could think about adding a new hook to "git am", though. It cannot just be an option to "git am" (or "git mailinfo") that says "if the input is .txt, assume European date order for \d+/\d+/\d+ dates, and otherwise assume US style", as that is too specific to your particular set-up and will not match general needs. If we were to add such a hook, $GIT_DIR/hooks/am-input-filter might look something like this (it is left as an exercise to enhance it to avoid munging a payload outside the header that happens to begin with "Date: "):

	#!/bin/sh
        case "$#" in
	0)
		cat
        	;;
	*)
        	for i
                do
                	case "$i" in
		        *.txt)
				sed -e 's/^\(Date: \)(\d+/)(\d+/)(\d+)/\1\3\2\4/' "$i"
				;;
			*)
                        	cat "$i"
				;;
			esac
		done
                ;;
	esac

and then teach "am" to use the hook, perhaps like the attached.

But at that point, wouldn't it be far simpler and cleaner if you did

	$ my-mbox-munge mail.txt | git am

in the first place?

 git-am.sh | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)