Обсуждение: Internationalized dates (was Internationalized error messages)

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

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

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

> >  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