Date: Mon, 28 Apr 1997 07:49:42 -0400
From: Robert Jasiek <jasiek@berlin.snafu.de>
Subject: Re: tight spec for game-info properties

> One big issue with the current format is what to do with partial dates.
> Often a file has just the year, or year and month.

Right, we need to discuss this a little.
Partial old dates are 'legal' for your program for evaluation 
if they contain year, or year and month,
if it is 'obvious' which numbers are which, if they consist of the
numbers and separators only, and if all separators are the same.

> I see entries like:

To sort them:

Put in accompanying date text field and issue a warning;
possibly convert to ;C[date: simpletext] (also see ;DC below):

> 1994-??-??
> Late 19th century  (well OK, I made this one up)
> July, 1991
> 17th of December 1992
> Sep 20 1991
> July 29 1989
> 8 sept 1990
> 3rd Korean World Title.\\\\
> 5-6 Juli 1963
> 3rd & 25th October, 1853
> 94.6.22

Obvious ISO-conversion (but notify user and let him confirm):

> 18-12-1990  
ISO: [1990-12-18]
> 1995-04-1   
ISO: [1995-04-01]
> 1820-04-10,30,05-14,15   
obviously FF[3] ISO, now:
[1820-04-10][1820-04-30][1820-05-14:1820-05-15] 

Partial ISO:

> 1994
> 1994-05

> Maybe 5 or 10 percent of my sgf files have the date in ISO format.
> It's hopeless to try to parse this much variety and convert to ISO.

In consideration of the low percentage you may as well put any FF[3]
date to the date text field.

> And many of these dates cannot be represented at all with the current FF[4]
> ISO date format.

So we see just how urgent a standard format is.

> This is the information I put in the text date field.  If I can
> parse the date, I put it in separate month/day/year fields.  If
> I can't, I put it in the text field.  When there is no date, the
> user can enter either mm/dd/yyyy or arbitrary text.

good

---

A few words about FF[4] short dates:
They should be possible, since exact dates are not always known.

Each ISO date of the Gregorian calendar or of the Julian 
calendar (if AC) can have one of the following subformats:

yyyy-mm-dd
yyyy-mm
yyyy

Meanings: Game progressed 
on yyyy-mm-dd
in yyyy-mm
in yyyy

With ;DT format
list of [date] | [Adate:Bdate]
Adate and Bdate are required to have the same subformat:

[yyyy-mm-dd:yyyy-mm-dd]
[yyyy-mm:yyyy-mm]
[yyyy:yyyy]

All other are illegal.
Besides it is required that Adate < Bdate. And in each DT property
each day can be mentioned at most once. And all [] property values
are to ordered in increasing date value.

Where to save non-ISO date texts (like the above or like an Edo 
date) so that the program knows that it is to be shown in an
accompanying date text field? I can think of three solutions:
- format expanded to: (list of [date] | [Adate:Bdate]) | simpletext
- format only: simpletext. Try to parse as 
  (list of [date] | [Adate:Bdate]) else interpret as simpletext.
- second date property ;DC of value simpletext for date comment

--robert jasiek