Re: [Yaml-core] Date fields

[<ir...@ms...>]

On Thu, Sep 05, 2002 at 04:47:24AM +0000, Clark C . Evans wrote:
> What specifically is wrong with timestamp?

A general date/datetime type needs to handle:
	2002-09-04               # default 00:00:00.000 Z
	2002-09-04 13:40         # default :00.000 Z
	2002-09-04 13:40:00      # default .000 Z
	2002-09-04 13:40:00.000  # default Z

Adding the missing features is apparently a trivial matter that most
people have accepted in principle.  

My problem with PyYAML is that in the following at least, the regex
recognizes the field as a timestamp but then converter raises a
ValueError because of the format.
	2002-09-12 20:00:00 Z
	2002-09-12 20:00:00
	2002-09-12 20:00

I was getting a different error on a date-only field (2002-09-12)
but now it's working, so that may have been a whitespace issue
rather than a timestamp issue.

A few applications operate at the month level and may prefer:
	2002-09                 # default -01 00:00:00.000 Z
but we've agreed it's not worth teaching YAML to recognize this.
Too many non-dates would be recognized as dates.  The .yml
maintainer can type 2002-09-01 instead.

YAML timestamps require a time zone and the default is Z.  Some 
applications want to be lazy and not specify a timezone, but still
treat the values as local time.  As long as the application remembers
not to look at the timezone attribute and treat it as significant -- and
as long as YAML doesn't do it unexpectedly behind the secenes -- this
should be OK.

Some applications require a dateless time type.
	13:40
	13:40:00
	13:40:00
This allows separate date and time fields so one part can be null if
unknown.  It's also useful for specifying repeating events or 
"how long something took".  Of course we can punt and leave this as
a string, but it seems funny to parse the date field and not the time
field.

Date defaults (and especially a dateless time type) bring up the
problem of false positives.  Social security numbers are 
DDD-DD-DDDD, but what if a similar number is DDD-DD-DD and one
document has 2002-09-04 and another document has 2002-13-32?
What if somebody catalogs their photos as "reel#:frame#", leading
to 12:02 and 24:61?

The false positive problem is so significant that I can also see
an argument for saying that timestamps are 
"DDDD-DD-DD DD:DD:DD.DDD+ TZ", end of story, and the regex won't 
recognize any shorter forms.  This makes the type unusable as a
general date/time type, but maybe that's OK.

Then there's the timestamp object the application actually gets.
I thought it was supposed to be mx.DateTime in PyYAML, but it's actually
yaml.timestamp .  It does some tricks to graft in DateTime functionality
and the methods look similar, but I'm not sure it's fully compatible.  I
haven't tried yet comparing a timestamp object to a DateTime object, but
that would be one thing I'd want to do.
	date >= mx.DateTime.today()
I just did
	isinstance(date, mx.DateTime.Date)
and freaked out when it returned false. :)

-- 
-Mike (Iron) Orr, ir...@ms...  (if mail problems: ms...@oz...)
   http://iron.cx/     English * Esperanto * Russkiy * Deutsch * Espan~ol