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

["Robert A. Schmied" <ras AT acm.org>]

Weigert, Thomas wrote:
> Yes, I agree. There is some confusion that needs to be untangled with
> respect to the different ways how dates are handled in different areas
> of the system. But I do like what ras has started with parse_date_str.
> I'll try to propose something...

i'm going jump in here just once more to try to explain why i went the
parse_date_str route and not attempt to change what i call gt 'internal'
date string formats. while i agree they may not truly be internal but
they seem interwoven into the fabric of gt.

believe me i've learned the hard way working with these date strings
and i'd like to see them fixed, but at the same time the larger picture
needs to be considered too: what will the impact be on all the user
files that drive, store or otherwise contain the original date strings.

also please notice the troubles todd turner is having with scan.pl.
i'm still trying to get to the bottom (top) of it, but his stuff
isn't working there, but i have yet to get a complete pedigree on it.
regardless, his system file works here without any of these recent
changes.

take the prior graphic.pl example using week time frame but passing
in day dates. gt internally operates with weekly series (yyyy-ww). this
is the most common offender i've run into (most frequently used other
than day) and we here in the usa don't really operate in weeks like
i believe they do in europe.

also consider the monthly and yearly date forms: yyyy/mm is not
really the same as yyyy-mm-dd when dd happens to be monday 25th
(extra month). there's probably a case were you're short a month too.

similarly --start 2000-06-01 --end 2007-06-01 isn't the exact same
thing as --start 2000 --end 2007 in a yearly time frame. in some
instances you can't get the exact granularity you may want.

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.

date::calc versus date::manip -- i don't know if the overhead of the
latter is excessive, but it does add very convenient date string
manipulations, however, date::manip isn't absolutely required to get
most of the benefit from parse_date_str. all the lifting is done
using date::calc to maintain total consistency with it's notion
of dates. this was a conscience choice way back when that sub was
being developed (in scan.pl).


aloha

ras


> Th.
>
>
> > -----Original Message-----
> > From: R P Herrold [mailto:herrold
AT
owlriver.com]
> > Sent: Friday, March 21, 2008 4:05 PM
> > To: devel
AT
geniustrader.org
> > Subject: [GT] Q re DateTime and Date format too
> >
> > On Fri, 21 Mar 2008, Robert A. Schmied wrote:
> >
> >
> > > Weigert, Thomas wrote:
> > >
> > > > Here is a tricky issue I discovered:
> > > >
> > > > The current code in DateTime::Month is inconsistent with both the
> > > > documentation and the usage in DateTime::Day.
> >
> > I've been watching this with some distance, but why not just
> > require the perl Date::Manip module and get with a general
> > solution?
> >
> > beancounter uses it, Finance-YahooQuote uses it, and it avoids
> > so much pain.
> >
> > - Russ herrold