http://www.cl.cam.ac.uk/~mgk25/iso-time.html

Requests:

1.  Offer full support for ISO-8601 right away.
2.  Make a plan to convert to ISO-8601 as the default, preferred time format in
the future.

> 1.  Offer full support for ISO-8601 right away.

Pro memoria, ISO 8601 is the ``YYYY-MM-DD'' date format.

Zoko, could you please spell out in full what you call ``full
support'' (list of all contexts where you want to see the format
accepted)?

And what about timezones?

                                        Juliusz

Well for starters, as per Tuomo Valkonen's bug report:
http://www.abridgegame.org/pipermail/darcs-devel/2005-November/003584.html

"""
Apparently the new bug tracking system requires registration, so you
can forget about me reporting stuff through it. Too cumbersome.

Anyhow, I really don't like using english/american date format everywhere.
I've written wrapper script for e.g. darcs changes to get nice ISO-8601
style dates. Now I was going to use 

	darcs changes --from-patch "date 2005-08-20"

but of couse this doesn't work:

	darcs: Can't support fancy dates.

*sigh*. There's nothing fancy about ISO-8601-style dates, they're very
simple and logically ordered. "Someday Somemonth Daynumber Time Zone Year." 
is fancy and illogically, and inconveniently ordered.

Please add support for ISO-style and/or locale dates as well for both 
input and output, or even better yet, switch completely to future, 
to ISO dates.

-- 
Tuomo
"""

ISO-8601 specifies nice language-independent, internationally standard timezone
notation, among other things.

One caveat to keep in mind is that ISO-8601 suggests using latin capital "T" to
separate date from time, as in 

2005-11-29T22:32:11

However, that is very ugly and I don't think the standard strictly requires it,
and I know for a fact that the "T" is usually replaced with a space as in:

2005-11-29 22:32:11

or, to make the time stamp a single token, an underscore as in:

2005-11-29_22:32:11

For example, Markus Kuhn's page on ISO-8601, while paying lip service to the
capital-T, actually uses the space-separated timestamps everywhere else.

Could timezone support get scrapped?  It isn't stored in patch, is it?

At the moment if one uses the horrid 14-digit fancy date, he is still
left without timezone, UTC assumed iirc.  This affects date selected,
for example when trying to find what patches there were on a certain day.

I'd be happy to work on an ISO 8601 parser.  Seems easy enough.  Can't say much
for request number 2 though.  Guess I'll set this back to unassigned when parser
is done.

ok, partial implementation sent to the list... no time intervals, truncations or
expansions, and the testing leaves much to be desired, but hope it helps
 
now working on improving the date matcher to allow stuff like "yesterday 23:12"

On Wed, Dec 28, 2005 at 01:37:33PM +0000, Eric Kow wrote:
> now working on improving the date matcher to allow stuff like "yesterday
> 23:12"

See also RT bug #34, which asks for a parser for date ranges (e.g. "in the
last three weeks", or "since Christmas").  The implementor of course could
decide how silly to get.  Git supports "tea time yesterday"... :)
-- 
David Roundy
http://www.darcs.net

Ok, I claim that our ISO-8601 support can be considered good enough to fulfill
request #1 (zooko? comments?). If this claim is correct, then the remaining
request is:

2.  Make a plan to convert to ISO-8601 as the default, preferred time format in
the future.

> 2.  Make a plan to convert to ISO-8601 as the default, preferred
> time format in the future.

Eric,

I might be misunderstanding what you're planning to do.  However, if
you're planning to make Darcs display big-endian dates by default,
please make sure you read the following.

Unlike what you have done until now, which was a clear improvement
with no change to the default user interface, this suggests changing
the default behaviour of darcs in a way that is culturally alien to
most people and incompatible with other revision control systems.
While I will not oppose such a change if there is a strong consensus
in favour of it, I am opposed to it myself.

                                        Juliusz

...
> the default behaviour of darcs in a way that is culturally alien to
> most people and incompatible with other revision control systems.
> While I will not oppose such a change if there is a strong consensus
> in favour of it, I am opposed to it myself.

Is it culturally alien to most darcs users?  I was under the impression that
ISO 8601 is the de facto standard among programmers.  Maybe this is just my
personal experience.

Anyway, what are we talking about here?  The display of times to the user ought
to be controlled by localization settings -- e.g. French users don't want to
see "Sun" instead of "Dim", nor do they want to see a United States/British
"April 10, 1998" instead of a French "10 avril 1998".

So if we're talking about imposing a non-localized alien representaton on
users, then we might as well impose an international standard without
foreign-language words in it instead of imposing the US/British convention.

But hopefully we're not talking about imposing on user display, but instead
talking about "canonical" representation which has to be identical for such
purposes as automated comparison, hashing, whatever.  It seems obvious to me
that such a thing ought to be ISO 8601.

Regards,

Zooko

Erm, I didn't have a concrete proposal there: I was just trying to bubble part 2
of that request up to a more visible position, i.e., to state that the job was
half done, and that perhaps we can now further discuss the second part.

On Jan 9, 2006, at 4:34 AM, Bennett Todd wrote:

> 2006-01-08T17:29:25 Juliusz Chroboczek:
>> Unlike what you have done until now, which was a clear improvement
>> with no change to the default user interface, this suggests changing
>> the default behaviour of darcs in a way that is culturally alien to
>> most people and incompatible with other revision control systems.
>
> Perhaps most other revision control systems have gotten this wrong,
> but I can't agree that 2006-01-09 is culturally alien to most
> people; rather, I think most people want either 01/09/2006 or
> 09/01/2006 and think that the one they prefer is natural. But I
> think everybody agrees that 2006-01-09 is sometime about now, while
> they would disagree whether the oddball formats are around now or in
> September.

Just to put in my $0.02.  I like the iso "big endian" dates.  I find  
them easy to sort on the command line and unambiguous.  I think this  
patch is a good thing.

Thanks,
Jason

By the way, I just noticed that roundup, originally designed by a security and
usability engineer that I respect, Ping Yee, has this to say about issue31:

"Created on 2005-11-30.02:07:35 by zooko, last changed 2006-01-10.02:37:22 by
dagit."

Looks like Ping substituted "." for "T".  (Anything is better than "T".)  I
imagine asking Ping about his choice of ISO-8601 and I imagine him expressing
surprise that one might consider using anything else...   :-)

> Erm, I didn't have a concrete proposal there:

> that perhaps we can now further discuss the second part.

I realise that.  I just wanted to make sure it's clear for everyone
involved that the discussion has not happened yet.

                                        Juliusz

Part 2 of this issue is moved to new issue140
Part 1 fixed in 1.0.6
Wed Dec 28 22:09:42 CET 2005  Eric Kow <eric.kow@gmail.com>
  * Extended date matching functionality. 
  (issue31 and RT #34)
  
  Now accepts ISO 8601 intervals (mostly) as well as a larger subset of
  English (including times like "yesterday at noon").
  
  Note: also includes corrections to ISO 8601 date/time parsing, using
  a more elegant technique of building dates up.

Bennett Todd wrote:

>But I
>think everybody agrees that 2006-01-09 is sometime about now, while
>they would disagree whether the oddball formats are around now or in
>September.
>
>Hmm. The other revision control system I have most convenient to
>hand (RCS) seems to call this 2006/01/09, so even though it's not
>using the ISO-8601 / RFC 3339 standard separator, it at least gets
>the order right.
>
>-Bennett
>  
>

Some more info on date formats and parsing:

    http://smokey.rhs.com/web/blog/rhs.nsf/stories/UpdateReNotesDateTime

together with the article that it updates:

http://smokey.rhs.com/web/blog/rhs.nsf/stories/NotesDateTimeAndInternationalFormats

(I found those by googling for "yyyy-dd-mm" :-)  It's about parsing 
dates from RSS feeds, which seem to have all kinds of formats, so his 
tips could be useful here.  Let me quote the footnote of the update article:

    "(Now, watch. Somewhere in the world, there's probably a small group 
of people who do in fact use YYYY/DD/MM, and I'll hear about it in the 
comments, won't I. I've had twenty plus years of experience in the 
software biz, including several years as a software localization 
specialist, and I've read countless articles and manuals covering 
international date and time formats (amongst many other things), and 
I've /never/ heard of anyone who uses YYYY/DD/MM format, but now that 
I've published an article, someone somewhere is going to have been 
offended by it..)"

But it seems nobody added a comment to this article saying s/he used 
YYYY/DD/MM format...

So my suggestion would be: at least *allow* date to start with a 
four-digit year, and then interpret the next two parts as month then day.

Groetjes,
 <><
Marnix

> So my suggestion would be: at least *allow* date to start with a 
> four-digit year, and then interpret the next two parts as month then day.

Yep, that seems like what we're doing already.  Re-resolving (see also issue140,
the discussion on what format dates should be displayed in).

Cheers,
Eric

Date matching is unfortunately rather broken now, but was masked by weak tests
in "match.pl" which were only testing that the dates parsed, not that any
matches were actually returned. 

I confirmed this with manual tests and a match I've just made to improve match.pl. 

(Unfortunately, darcs-devel appears to be broken now, so I mailed droudy
directly as well. ). 

My updated tests may be sensitive to which time zone and time of day you run
them in. They expect that if a patch says it was recorded at "10:01:02 EST" on
the 8th, then you could find it by searching for "2008-01-08", but that is not
the case. It will match on '2008-01-09' instead, perhaps it matching against a
UTC representation of the date, which is occurs several hours later (??). 

The updated test also expects that "darcs changes" will always report dates in
English. I'm not sure if that's an accurate assumption.

On Thu, Jan 10, 2008 at 03:27:55AM -0000, Mark Stosberg wrote:
> My updated tests may be sensitive to which time zone and time of day you run
> them in. They expect that if a patch says it was recorded at "10:01:02 EST" on
> the 8th, then you could find it by searching for "2008-01-08", but that is not
> the case. It will match on '2008-01-09' instead, perhaps it matching against a
> UTC representation of the date, which is occurs several hours later (??). 

I think this is safe (if dates are always printed in English).
The date parser assumes times and dates are given in the local
time zone, and 'darcs changes' prints times and dates according
to the local time zone. The match test reads the literal output
from 'darcs changes' and feeds those numbers back to --match,
i.e., everything is in the same time zone all the time.

> The updated test also expects that "darcs changes" will always report dates in
> English. I'm not sure if that's an accurate assumption.

I haven't checked the source, but on my machine with Swedish
locale the dates from 'darcs changes' are still printed in
English. However, they are (as stated above) converted to my
local time zone CET (or CEST during summer), and the date parser
can not parse CET as a time zone string, so the match_date test
with explicit time zone in it fails on my computer. Funny enough
the date parser can parse CEST.

One solution is to add a bunch of time zone strings to the date
parser. I've already started this, but found out some time zone
strings are ambiguous, so the test can never work reliably for
all time zones. Another solution is to set the TZ environment
variable to UTC at the beginning of the match test. Then 'darcs
changes' will print (and parse) dates in UTC time zone, which is
one of the time zone strings the date parser can parse. A third
solution is to remove the test with explicit time zone.

Hm, is it possible with perl to first check if we can parse the
local time zone string, and only if we can do so proceed with
the match test?

On Sun, Jan 20, 2008 at 10:24:05PM -0000, Tommy Pettersson wrote:
> On Thu, Jan 10, 2008 at 03:27:55AM -0000, Mark Stosberg wrote:
> > My updated tests may be sensitive to which time zone and time of day you run
> > them in. They expect that if a patch says it was recorded at "10:01:02 EST" on
> > the 8th, then you could find it by searching for "2008-01-08", but that is not
> > the case. It will match on '2008-01-09' instead, perhaps it matching against a
> > UTC representation of the date, which is occurs several hours later (??). 
> 
> I think this is safe (if dates are always printed in English).

I take that back! It's currently 00:50 here in time zone +0100,
and the date matcher does NOT match a patch created "yyyy-mm-dd
00:50 +0100" with the date "yyyy-mm-dd". :-(

regarding parsing the time zone identifiers...it known that they can be
ambiguous. For example, EST can be both "Eastern Standard Time" and "European
Summer Time", which are rather different. The unambiguous was to represent a
time zone is the format of "America/New_York". 

My vote is to make these kinds of tests more relaxed, because this kind of
output is the friendliest for the user, even if it is more difficult to test. 

Related to this, several of the "match.pl" tests have been consistently failing
for me lately. I assume that they must be passing for others, or maybe it's
related to a different in my repo. 

Anyhow, it's a chance to showoff the "failures only" mode of the new harness I
"sent" yesterday:

( I'm also assigning this to droundy, who worked on the updates most recently. )

$ ./bin/prove --failures --nocolor match.pl
match.......1/?
not ok 1 - date format 2008-01-20 finds a match

#     Failed test (match.pl at line 225)
#                   ''
#     doesn't match '(?-xism:tester)'
not ok 2 - date format 20080120 finds a match

#     Failed test (match.pl at line 225)
#                   ''
#     doesn't match '(?-xism:tester)'
match.......41/? not ok 41 - date format Sun Jan 20 20:07:04 EST 2008 finds a match

#     Failed test (match.pl at line 225)
#                   ''
#     doesn't match '(?-xism:tester)'
match.......47/? not ok 48 - date format 2008/01/20 20:07:04 finds a match

#     Failed test (match.pl at line 225)
#                   ''
#     doesn't match '(?-xism:tester)'
not ok 49 - date format 2008/01/20 20:07:04 EST finds a match

#     Failed test (match.pl at line 225)
#                   ''
#     doesn't match '(?-xism:tester)'

I've been looking at this a little, and the problem is that the
CalendarTimes read from the patch infos has a zero time zone
offset (UTC), but the CalendarTimes parsed from the user are in
either the users local time zone or the time zone explicitly
given in the date, and the comparison functions does not adjust
for any difference in time zone offset.

I made a simple fix where I converted all times parsed from the
user to UTC, so that the time zone offset would be equal, but
that broke David's "short date" (year / year-month) hack,
because the conversion "fixed" the 0 day (I think).

I've been thinking some more, and the only right way for
sameDate to work intuitively, is to convert both compared dates
to the time zone of The Entered Date (default to user's local
time zone). E.g., if one wants to match patches with date
"2008-01-21 FTZ" (not real example), one should convert every
compared patch info date to FTZ before comparing the year, month
and day. The reason why I think so is that a user is likely to
enter the dates shown by 'darcs changes', which are in the
user's local time zone. (After all, this is how the match.pl
test does it -- which fails.)

So patch date matching is not a generic date comparison, because
it has a given time zone it must work with. Likewise, date
"between 2008-01-21 ATZ && 2008-01-22 BTZ" (not real example)
should test if the patch info date lies between 2008-01-21 when
converted to ATZ and 2008-01-22 when converted to BTZ. Together
with the extra feature that date matching should work for only
year and year-month, e.g., date "between 2007 ATZ and 2008-01
BTZ", it is clear that it requires some redesign.

On Mon, Jan 21, 2008 at 06:54:12AM -0000, Tommy Pettersson wrote:
> I've been thinking some more, and the only right way for
> sameDate to work intuitively, is to convert both compared dates
> to the time zone of The Entered Date (default to user's local
> time zone). E.g., if one wants to match patches with date
> "2008-01-21 FTZ" (not real example), one should convert every
> compared patch info date to FTZ before comparing the year, month
> and day. The reason why I think so is that a user is likely to
> enter the dates shown by 'darcs changes', which are in the
> user's local time zone. (After all, this is how the match.pl
> test does it -- which fails.)
> 
> So patch date matching is not a generic date comparison, because
> it has a given time zone it must work with. Likewise, date
> "between 2008-01-21 ATZ && 2008-01-22 BTZ" (not real example)
> should test if the patch info date lies between 2008-01-21 when
> converted to ATZ and 2008-01-22 when converted to BTZ. Together
> with the extra feature that date matching should work for only
> year and year-month, e.g., date "between 2007 ATZ and 2008-01
> BTZ", it is clear that it requires some redesign.

Yes, this makes sense.  Any chance you'd be willing to put this together?
Another alternative would be to make sameDate asymmetric, either way should
work, I think.
-- 
David Roundy
Department of Physics
Oregon State University

[...]
> Yes, this makes sense.  Any chance you'd be willing to put this together?

I would certainly enjoy it, if I can only find the time. But
I'll do 1.0.10 first. This date adventure of mine was an attempt
to fix this issue for 1.0.10 (and darcs2 of course), but it
turned out to be a little more work than I expected.

Hi Tommy,

I can't promise much, but if it helps, I'm currently looking into extending the
match.pl tests to be a little more informative.  My basic approach is to use
record --pipe to specify a date manually.  It won't be as good as using real
world dates (i.e. from the system) because now we're just testing if our date
parser is internally consistent, but seems like a step forward anyway

I'll also add that I'm working on a less-hacky way of supporting unspecified
parts of dates (2007-03 meaning all of March), which I got way wrong the first
time around.

Basic idea so far is

data MCalendarTime = MCalendarTime
 { mctYear  :: Maybe Int
 , mctMonth :: Maybe Month
 , mctDay   :: Maybe Int
 , mctHour  :: Maybe Int
 , mctMin   :: Maybe Int
 , mctSec   :: Maybe Int
 , mctPicosec :: Maybe Integer
 , ctWDay     :: Maybe Day
 , ctYDay     :: Maybe Int
 , ctTZName   :: Maybe String
 , ctTZ       :: Maybe Int
 , ctIsDST    :: Maybe Bool
}

Eric, 

If it helps, here's some GPL source code (in Perl) which also tackles incomplete
dates. Click the "source" link at the top of the page for the guts:

http://search.cpan.org/~fglock/DateTime-Incomplete-0.03/lib/DateTime/Incomplete.pm

   Mark

Tommy and Mark,

I have sent off a bundle starting with

Sun Jan 27 09:29:31 MST 2008  Eric Kow <E.Y.Kow@brighton.ac.uk>
  * Make documentation on dates more explicit.

It may fix some of the bugs you noticed here.  I think it might be a good idea
to review this code, seeing the mess I made of it the first time around.

Well, for some reason or another I can't seem to send to darcs-devel@darcs.net.
Here's my patches attached to the tracker. Somebody should probably go through
and watch for any more stupid stuff I may have introduced.

Attachments

• 2008-01-27-iso-dates.dpatch

I think Eric's patches fix this bug, so I'm marking resolved-in-unstable. 
Thanks Eric!