Re: A creepy story about dates. How to prevent it?

Wasn't a 'set' command also discussed to override locale?

On Tue, 2003-06-24 at 16:02, Bruce Momjian wrote:
> Good point.
>
> ---------------------------------------------------------------------------
>
> scott.marlowe wrote:
> > I thought it was more correctly we were considering not using the the
> > system locale automatically, but that if someone wished to use
> > --locale=en_US we'd let that work, right?
> >
> > I would assume that if someone actually went to the bother of setting a
> > locale, then it should be the deciding factor in how we handle dates, et.
> > al.
> >
> > On Tue, 24 Jun 2003, Bruce Momjian wrote:
> >
> > >
> > > We are actually considering not honoring locale for initdb encodings, so
> > > it might make no sense to do this --- that another reason for the
> > > question mark, but until we decide, it is an open issue.
> > >
> > > ---------------------------------------------------------------------------
> > >
> > > Lincoln Yeoh wrote:
> > > > At 03:24 PM 6/23/2003 -0400, Bruce Momjian wrote:
> > > >
> > > > >Added to TODO, with question mark:
> > > > >
> > > > > * Have initdb set DateStyle based on locale?
> > > >
> > > > Given various issues with locale (indexes, ordering etc) I'd think that
> > > > having a DB follow the O/S locale should be special case and require
> > > > explicit configuration.
> > > >
> > > > More so if certain locales are significantly slower than others which
> > > > seemed to be the case at least in recent memory.
> > > >
> > > > What if a European DB backed website is hosted on a US server with English,
> > > > French and German data?
> > > >
> > > > If apps/programs are talking to DBs more than people are then it may make
> > > > more sense to store things in an application friendly format e.g. (date =
> > > > YYYY-MM-DD, or seconds since epoch) format and having the app convert it
> > > > based on the user's preferences. After all even in English, apps may choose
> > > > to display Tuesday as T, Tue, Tuesday, or whatever the Boss wants.
> > > >
> > > > Unless postgresql has special features allowing switching from one locale
> > > > to another on the fly (including indexes, ordering etc) within a DB
> > > > session, I'd rather stick to say the C locale, or whatever it is that's
> > > > fastest.
> > > >
> > > > Another point of consideration: if someone accidentally loads
> > > > multibyte/other locale data into a C locale DB (or whatever is chosen as
> > > > default DB locale), would dumping the loaded data and reloading it into a
> > > > multibyte locale result in information/precision loss?
> > > >
> > > > Link.

--
+-----------------------------------------------------------+
| Ron Johnson, Jr. Home: ron(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "Oh, great altar of passive entertainment, bestow upon me |
| thy discordant images at such speed as to render linear |
| thought impossible" (Calvin, regarding TV) |
+-----------------------------------------------------------