Now you're talking about i18n, maybe someone could think about input and
output of dates in local language.

As fas as I can tell, PostgreSQL will only use English for dates, eg January,
February and weekdays, Monday, Tuesday etc. Not the local name.

-- 
Kaare Rasmussen            --Linux, spil,--        Tlf:        3816 2582
Kaki Data                tshirts, merchandize      Fax:        3816 2501
Howitzvej 75               ï¿½ben 14.00-18.00        Email: kar@webline.dk
2000 Frederiksberg        Lï¿½rdag 11.00-17.00       Web:      www.suse.dk

Fri, 9 Mar 2001 22:58:02 +0100
Kaare Rasmussen <kar@webline.dk>
Internationalized dates (was Internationalized error messages)
On Fri, Mar 09, 2001 at 10:58:02PM +0100, Kaare Rasmussen wrote:
> Now you're talking about i18n, maybe someone could think about input and
> output of dates in local language.
> 
> As fas as I can tell, PostgreSQL will only use English for dates, eg January,
> February and weekdays, Monday, Tuesday etc. Not the local name.

 May be add special mask to to_char() and use locales for this, but I not
sure. It isn't easy -- arbitrary size of strings, to_char's cache problems
-- more and more difficult is parsing input with locales usage. 
The other thing is speed...

 A solution is use number based dates without names :-(
 
			Karel

PS. what other SQL engines, support it?

-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

Mon, 12 Mar 2001 11:11:46 +0100
Karel Zak <zakkr@zf.jcu.cz>
Re: Internationalized dates (was Internationalized error messages)
On Mon, Mar 12, 2001 at 11:11:46AM +0100, Karel Zak wrote:
> On Fri, Mar 09, 2001 at 10:58:02PM +0100, Kaare Rasmussen wrote:
> > Now you're talking about i18n, maybe someone could think about input and
> > output of dates in local language.
> > 
> > As fas as I can tell, PostgreSQL will only use English for dates, eg January,
> > February and weekdays, Monday, Tuesday etc. Not the local name.
> 
>  May be add special mask to to_char() and use locales for this, but I not
> sure. It isn't easy -- arbitrary size of strings, to_char's cache problems
> -- more and more difficult is parsing input with locales usage. 
> The other thing is speed...
> 
>  A solution is use number based dates without names :-(

ISO has published a standard on date/time formats, ISO 8601.  
Dates look like "2001-03-22".  Times look like "12:47:63".  
The only unfortunate feature is their standard format for a 
date/time: "2001-03-22T12:47:63".  To me the ISO date format
is far better than something involving month names. 

I'd like to see ISO 8601 as the default data format.

--
Nathan Myers
ncm@zembu.com

Mon, 12 Mar 2001 13:54:30 -0800
ncm@zembu.com (Nathan Myers)
Re: Internationalized dates (was Internationalized error messages)
> >  A solution is use number based dates without names :-(
> ISO has published a standard on date/time formats, ISO 8601.
> Dates look like "2001-03-22".  Times look like "12:47:63".
> The only unfortunate feature is their standard format for a
> date/time: "2001-03-22T12:47:63".  To me the ISO date format
> is far better than something involving month names.
> I'd like to see ISO 8601 as the default data format.

You got your wish when 7.0 was released; the default date/time format is
"ISO" which of course can be adjusted at build or run time.

The default date/time formats are compliant with ISO-8601 (or are at
least intended to be so). The detail regarding "T" as the time
designator mentioned above is covered in 8601 and our usage, omitting
the "T", is allowed by the standard. At least as long as you agree that
it is OK! The wording is actually:

... By mutual agreement of the partners in information interchange, the
character [T] may be omitted...

Presumably this can be covered under our documenting the behavior (and
by compliance with common and expected usage), rather than requiring
100% concurrence by all end users of the system ;)

                       - Thomas

Tue, 13 Mar 2001 02:46:11 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Internationalized dates (was Internationalized error messages)