RE: [GT] Q re DateTime and Date format too

["Weigert, Thomas" <weigert AT mst.edu>]

You put your finger on the core of the problem: When entering a date it
must be interpreted in the context of the timeframe. There is no such
thing as "half a time period", so as you say, entering some date in 2008
means the whole year in a yearly timeframe. Entering the last day of
January means the whole January, etc.

So the question is as to what is more intuitive and less annoying for
the user:

1. A date such as "2008-04-12" is being mapped to "2008" in a yearly
timeframe, "2008/04" in a monthly timeframe, to "2008-15" in a weekly
timeframe, etc., so that date formats do not need to be changed when
different timeframes are being considered.

Or 

2. A date must be used in the syntax that is appropriate for its
timeframe, e.g., "2008-04-12" for a daily timeframe, "2008-15" for a
weekly timeframe, "2008/4" for a monthly timeframe, "2008" for a yearly
timeframe so that date formats need to be changed whenever timeframes
change.

However, I believe that the current situation is not the right one, as
currently:
- "2008-04-12" aborts in monthly timeframe
- "2008-04-12" is interpreted as "2008-04" in a weekly timeframe
- "2008-04-12" is interpreted as "2008" in a yearly timeframe.
these inconsistencies are the most confusing, I believe.

My personal preference is for (1) augmented by documentation. Inclusion
of ras's new date parser would be a good way of driving for this
consistency.

Th.

> -----Original Message-----
> From: Robert A. Schmied [mailto:ras
AT
acm.org]
> Sent: Friday, March 21, 2008 6:58 PM
> To: devel
AT
geniustrader.org
> Subject: Re: [GT] Q re DateTime and Date format too
> 
 
> for what it's worth, i'd recommend and encourage that we leave the
> datetime alone, warts and all, and concentrate on making the user date
> string interface more human date friendly, but at the same time
> warn the user that, for example, --start 2000-06-01 in a year time
> frame means all of 2000 not just half (unless you want to round the
> other way and then use none of 2000).
> 
> but i'm not against adding better error (warning) messages in datetime
> to satisfy thomas' issue about getting totally unhelpful errors.
although
> i'd argue by doing better up front date string checking and
appropriate
> time frame conversion, improvements to datetime shouldn't be needed,
> as it provides internal gt date time methods and shouldn't be used by
> the user.
>