Re: [mdb-dev] Opinions about date formats

[Glenn T. <gl...@tr...>]

[I forgot to copy the list on this message.]

If you send me the FreeTDS date code, I'd be happy to look at integrating
it.  Looks like I need to build a Linux box to check out things like
libcalendar.  Could you recommend a distro?  And where to get a CD?

I'm not so worried about internationalization, especially if we use a 4-digit
year, since I doubt that people are using mdbtools to present
end-results to
users.  My impression is that most users just want to suck the data out and
put it into another database.  In that case, the date/time just has to be
unambiguous.  (I'd consider using YYYY/MM/DD, if there was any call for it.)

Of course, you would know best how people are using mdbtools.  Do you
know of
mdbtools users that care that much about mdbtools producing internationalized
date formats?

Thanks,
    Glenn

Brian Bruns wrote:

> My plan was this (as usual, I'm just telling you what my intentions were,
> not that you should or shouldn't follow it.  Do what you feel).  Anyway,
> I was going to use the code from FreeTDS (I do a lot of borrowing) for
> dates out of range, thus no dependency on libcalendar.  As far as format,
> each backend would have a format string that would be used to format the
> dates acceptible to that database, and probably needs to handle
> internationalisation as well, but I'm not sure how to tie that in yet.
>
> Brian
>
> On Mon, 12 Aug 2002, Glenn Trewitt wrote:
>
> > Right now, the various utilities export dates in the format:
> >     MM/DD/YY HH:MM:SS
> > and the current routines produce garbage when the date is out of range
> > of the UNIX 32-bit time_t type.
> >
> > I'm going to fix the garbage problem, as mentioned in an earlier
> > message:  I'll use the "libcalendar" library, if it's present on the
> > system to produce the correct dates.  If it's not available, I'll use
> > the current scheme, but output a distinctive symbol to indicate an
> > out-of-range date.
> >
> > That leaves me with two questions:
> > 1) What should the symbol(s) be?  Potentially, there could be one for
> > "earlier than the epoch" and one for "later than the next epoch".  I
> > have a feeling that any sufficiently distinctive date would likely cause
> > imports to other databases to fail with an error, which would be bad.
> > The only other choice seems to be to use "00/00/00 00:00:00"
> >
> > 2) What about 4-digit years?  Using 2-digit years just seems wrong, but
> > changing it might break imports into other software that is expecting
> > 2-digit years.  The other possible bad side-effect is that it would
> > uncover ridiculous dates in existing databases that are currently hidden
> > by masking off the century.  In my databases, I've got a few "1899" and
> > "1000" dates.  However, I think that it would be better to flush them
> > out and explicitely deal with them.
> >
> > Another option is to add global options to control the date formats
> > used, but that seems like complete overkill.
> >
> > Unless I hear otherwise, I'm going to:
> >     Use "00/00/00 00:00:00" when libcalendar is unavailable and a date
> > is out of range.
> >     Change to use 4-digit years.
> >
> > Comments are requested.
> >     - Glenn Trewitt
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Dice - The leading online job board
> > for high-tech professionals. Search and apply for tech jobs today!
> > http://seeker.dice.com/seeker.epl?rel_code=31
> > _______________________________________________
> > mdbtools-dev mailing list
> > mdb...@li...
> > https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
> >
> >