Re: A creepy story about dates. How to prevent it?
От | Lincoln Yeoh |
---|---|
Тема | Re: A creepy story about dates. How to prevent it? |
Дата | |
Msg-id | 5.2.1.1.1.20030624231310.02e373f0@mbox.jaring.my обсуждение исходный текст |
Ответ на | 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?
Re: A creepy story about dates. How to prevent it? |
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: