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

Поиск
Список
Период
Сортировка
От Ron Johnson
Тема Re: A creepy story about dates. How to prevent it?
Дата
Msg-id 1056325180.10234.5.camel@haggis
обсуждение исходный текст
Ответ на Re: A creepy story about dates. How to prevent it?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: A creepy story about dates. How to prevent it?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-general
On Sun, 2003-06-22 at 15:47, Bruce Momjian wrote:
> Ron Johnson wrote:
> > On Sun, 2003-06-22 at 12:46, Bruce Momjian wrote:
> > > Ron Johnson wrote:
> > > > On Sun, 2003-06-22 at 00:05, Bruce Momjian wrote:
> > > > > Bruce Momjian wrote:
> > > > > >
> > > > > > Reading the subject, "creepy ... dates", that is exactly how I feel
> > > > > > about the described current date behavior --- "creepy".
> > > > > >
> > > > > > Because I have only seen one person defend our current behavior, and
> > > > > > many object, I am going to add to TODO:
> > > > > >
> > > > > >     * Allow current datestyle to restrict dates;  prevent month/day swapping
> > > > > >           from making invalid dates valid?
> > > > > >     * Prevent month/day swapping of ISO dates to make invalid dates valid
> > > > >
> > > > > I added a question mark to the first item so we can consider it later.
> > > > > Most agreed on the second item, but a few thought the first one might be
> > > > > OK as is.
> > > >
> > > > How about situations where reversing the month and date would
> > > > still have "valid but wrong" dates, based upon the LOCALE mask?
> > > >
> > > > I.e., "05/04/2003" is "05-April-2003" or "04-May-2003", depending
> > > > on whether the LOCALE implies "DD/MM/YYYY" or "MM/DD/YYYY".
> > > >
> > >
> > > My assumption is that we already handlle these OK because we base it on
> > > datestyle.
> >
> > According to the OP, no.
>
> Oh, you are right.  We base it on datestyle, rather than locale.  Is it
> desiarable to default postgresql.conf datestyle to match the locale?
>
>     #
>     #       Locale settings
>     #
>     # (initialized by initdb -- may be changed)
>     LC_MESSAGES = 'C'
>     LC_MONETARY = 'C'
>     LC_NUMERIC = 'C'
>     LC_TIME = 'C'

As long as it's overridable by a "masking set statement", does
it matter?  Well, it probably does, for consistency's sake.

P.S. - candle.pha.pa.us rejects email from smtp.east.cox.net
because "Delivery blocked --- Previous SPAM received from your
mail server".  That's blocking a *lot* of valid email, since
cox.net is pretty large.

--
+-----------------------------------------------------------+
| Ron Johnson, Jr.     Home: ron.l.johnson@cox.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)               |
+-----------------------------------------------------------


В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Aggregate functions on ordered data?
Следующее
От: "Ned Lilly"
Дата:
Сообщение: Re: [pgsql-advocacy] interesting PHP/MySQL thread