Ambiguous date handling

2012-09-12 Thread Chris Packham
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

Re: Ambiguous date handling

2012-09-12 Thread Junio C Hamano
Chris Packham judge.pack...@gmail.com writes: 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

Re: Ambiguous date handling

2012-09-12 Thread Chris Packham
On 09/12/2012 09:48 PM, Junio C Hamano wrote: Chris Packham judge.pack...@gmail.com writes: 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

Re: Ambiguous date handling

2012-09-12 Thread Junio C Hamano
Chris Packham judge.pack...@gmail.com writes: 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. Yuck. Could this be done in a applypatch-msg hook? Isn't the hook about fixing up the log

Re: Date handling.

2005-04-14 Thread David Woodhouse
On Thu, 2005-04-14 at 02:12 -0700, Linus Torvalds wrote: I take that back. I'd be much happier with you doing and testing it, because now I'm crashing. OK. commit-tree now eats RFC2822 dates as AUTHOR_DATE because that's what you're going to want to feed it. We store seconds since UTC epoch,

Re: Date handling.

2005-04-14 Thread David Woodhouse
On Thu, 2005-04-14 at 12:19 -0700, [EMAIL PROTECTED] wrote: With a UTC date, why would anyone care in which timezone the commit was made? Any pretty printing would most likely be prettiest if it is done relative to the timezone of the person looking at the commit record, not the person who

RE: Date handling.

2005-04-14 Thread Luck, Tony
I'd prefer not to lose the information. If someone has committed a change at 2am, I like to know that it was 2am for _them_. It helps me decide where to look first for the cause of problems. :) I'd think the 8:00am-before-the-first-coffee checkins would be the most worrying :-) It also helps