This is a new issue for part 2 of issue31 (ISO-8801 dates)

Some notes which may be useful for both sides of the debate.  

I assume we are talking about the format with which we _output_ dates, for
example in the darcs send summary of patches.  Looking at the code
(PatchInfo.friendly_d), I get the impression that we were intending to print out
localised dates, but due to an error in the haskell libs (?) we always get
American ones.

The reason I point this out is to suggest that maybe the current behaviour of
printing out US dates is unintentional, in that maybe if darcs printed out
whatever dates fit into your local convention, there would be less of a cry for
iso8601 dates.

why we get US dates instead of local ones
------------------------------------------
At least, that's what System.Time.calendarTimeToString promises us, but no
matter how you set the locale, you systematically get American dates.  Why is
this? I believe that it is either a bug or just misleading API documentation in
the Haskell libs.  The function calenderTimeToString seems to assume that
defaultTimeLocale gives us the local locale, for example, fr_FR, whereas
defaultTimeLocale is hard coded with some English strings.  The problem seems to
be some subset of the following errors
1) calendarTimeToString documentation - should not claim to format thingns using
local conventions?
2) defaultTimeLocale documentation - should not claim to use local conventions
3) calendarTimeToString implementation - should not use defaultTimeLocale
4) defaultTimeLocale implementation - should not be hard coded

I suppose a good next action to undertake here might be to contact some haskell
people and see what they think.  I'm not sure how one would fix this.  I imagine
you'd need something in IO which gets you the local conventions, and then be
willing to make an unsafe call to it at some point.

where do we go from here?
-------------------------
It seems we have 3 options, which of course, may be mixed and matched

1. status quo - keep the US dates; note that if the haskell lib folk agree that
the above is a bug, then we may have to change our code to keep our behaviour
2. fix things and get locale-driven dates
3. systematically output iso8601 dates

Note that #2 might not be so good for the darcs send summaries, especially if
you're doing the whole darcs-send-to-mailing-list thing.  English speakers might
be confused by French dates, for example.  Then again, who really looks at the
dates in these things anyway?

Also, for #3, I do find that a string of numbers is harder for a human being to
parse than a nicely spaced out string with mixed numbers and letters, that is that
2006-05-22 14:26:55+0200
is a bit more difficult for me than
Mon May 22 14:26:55 CEST 2006

If we were to go to number #3 in the name of universal unambiguity, I'd suggest
we make a small concession to human-friendliness by prefixing the date with
(xxx) where xxx is the day of the week, preferably localised.  So what we'd get
is something like
(Mon) 2006-05-22 14:26:55+0200

Computers then would know to throw away the first 5 characters, and human beings
would be able to say, "oh ok, Monday, two days ago"

Regarding defaultTimeLocale, I think that either it is supposed to return the 
POSIX/anglophone time format, or it has incorrect type. For the locale's time 
format depends on setlocale() (which doesn't seem to exist in the GHC/Haskell 
standard libraries), and thus we should have defaultTimeLocale :: IO TimeLocale.

As for readability of formats, I find the ISO-8601 style format much easier to 
read than the anglophone format with illogical (month day ... year) ordering and 
non-numeric month, my native format being 22.5.2006 14:26:55+0200, which is like 
ISO-8601 but with the day number in reversed order.

kowey wrote: "Also, for #3, I do find that a string of numbers is harder for a
human being to parse than a nicely spaced out string with mixed numbers and
letters, that is that
2006-05-22 14:26:55+0200
is a bit more difficult for me than
Mon May 22 14:26:55 CEST 2006"

This is partially a matter of practice.  People who grew up in different
cultures have different experiences of this.  Personally, I have been using ISO
8601 for so many years that I find the ISO 8601'ish string above easier to read
than the American string.

"If we were to go to number #3 in the name of universal unambiguity, I'd suggest
we make a small concession to human-friendliness by prefixing the date with
(xxx) where xxx is the day of the week, preferably localised.  So what we'd get
is something like
(Mon) 2006-05-22 14:26:55+0200"

This format looks fine to me.

I think that we should use a format like this one as the default if there is not
a local-culture-specific format that the user prefers.

Oh, except that the day-of-the-week thing is culture-specific.  If we put it
after instead of before then it will be easier for computers to ignore it.  (For
example, what about cultures that use two or four chars for weekday names
instead of three?)

How about this:

2006-05-22 14:26:55+0200 (Mon)

>  2006-05-22 14:26:55+0200 (Mon)

Alternatively, if a simple day-of-week doesn't tell the human very
much, we could go for a short text date

2006-05-22 14:26:55+0200 (3 Jan)

Or some combination.  And since we're already being neutral by giving
an ISO date, we could do this in English for ease of implementation
:-P

So I for one would be happy with this format becoming the default one:

2006-05-22 14:26:55+0200 (3 Jan)

The first part is ISO-8601 (except with space instead of 'T' between the date
and the time) and the format of the last part is up to kowey or other people who
don't read ISO-8601 natively.  :-)

I don't hear any strong objections to this (outputting ISO 8601 dates, perhaps
with some trailing junk for easy reading).  Please note that this issue is only
about what dates _outputs_ to the user, for example, in darcs changes, or in
darcs send.  Nothing else (patch formats, XML) changes.

On Thu, Aug 28, 2008 at 01:30:36PM -0000, Eric Kow wrote:
> I don't hear any strong objections to this (outputting ISO 8601 dates, perhaps
> with some trailing junk for easy reading).  Please note that this issue is only
> about what dates _outputs_ to the user, for example, in darcs changes, or in
> darcs send.  Nothing else (patch formats, XML) changes.

I would say that it makes sense to me to make this configurable, if
we're going to change darcs' behavior.  We never find out about the
unwashed masses who like darcs' current behavior until we change it.

David

> I would say that it makes sense to me to make this configurable, if
> we're going to change darcs' behavior.  We never find out about the
> unwashed masses who like darcs' current behavior until we change it.

Ok, I would suggest using the ISO format by default, and allowing the
DARCS_DATE_FORMAT environment variable using the same format
understood by the Unix date program to override it (with documentation
showing the format you need to set it to to get the old format)

I think this has been fixed a long time ago.