Skip to Content.
Sympa Menu

freetds - Re: Date Problem

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT speakeasy.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Date Problem
  • Date: Sun, 09 Dec 2001 12:05:38 -0500


Eric Deutsch wrote:
>
> It would be sensational if one could specify in freetds.conf one's own
> strftime format string. I like all my dates to show up as
> '2001-12-07 15:45:22' without having to CAST and CONVERT and stuff.

Eric,

When I first read your message, my reaction was "Great idea!" There are
a couple of concerns I have, though.

The most important issue is breaking existing code, especially
third-party applications. FreeTDS doesn't (and shouldn't) have any way
to know what application is using what connection, and the freetds.conf
entry AIUI would affect all connections equally. That's bound to
surprise any non-custom software. Since FreeTDS gets used with a lot of
stuff, I think the probability of surprise approaches 1 over time.

The secondary issue is support. I have this idea that someone might
read in the documentation that he can affect his default date format,
set the entry in his freetds.conf, and some time later notice that xyz
feature mysteriously breaks in his PHP script. And the first answer
would be "make sure there's no strftime stuff in your freetds.conf." A
bug waiting to happen, if you see what I mean.

Some alternatives:

1. Put the strftime format string in some easy-to-locate place to make
patching the code simple.
2. Add a --withstrftime configure switch. <ducking...>
3. Add an API to set the strftime string per connection (spid).

I'm not saying No, I'm just asking whether any of these ideas aren't as
good or better. Their advantage is that none of them breaks a working
environment without recompiling. In general, I like to be able to
affect software's behavior without recompiling, because it's easier for
non-programmers and programmers alike. In this case, though, since only
custom applications could handle the effect, it seems better (to me) to
make it a compile-time feature.

Regards,

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page