From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Thomas Good <tomg(at)sqlclinic(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ian Barwick <barwick(at)gmx(dot)net>, Postgres SQL List <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Date Anomaly?? |
Date: | 2003-05-07 15:36:34 |
Message-ID: | 200305070836.34610.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Thomas,
> > > Another item: if I say 'export PGDATESTYLE=US' and ask psql for
> > > the date I get back an ISO date (YYYY-MM-DD). What region of this
> > > US is this, I wonder? Must be San Francisco (maybe Josh knows ;-)
Yeah, it's my fault. Here in SF we're never sure what year it is, so we put
the year first. <grin>
> Bottom line: there is no way to return a MM-DD-YYYY value?
Really easy, actually:
SELECT to_char(datefield, 'MM-DD-YYYY');
> I never realised that the morphology of the traditional Postgres date
> was this complex (its declension was not apparent until I used the
> INTERVAL keyword) and so I've conditioned my users to using hyphens
> as delimiters...argh. Should have used slashes I suppose.
That's the price you pay for having "real" dates instead of the delimited
string stored by other, less sophisticated, database systems.
One of the things on my todo list (Item #18, though) is a pl/perl function
that will accept any reasonable US date and return ISO standard for insert;
I'll post it to the list when I'm done (maybe next week).
--
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-05-07 15:37:25 | Re: ERROR:Â pg_atoi: error in "NULL": can't parse "NULL" |
Previous Message | Mendola Gaetano | 2003-05-07 15:36:29 | Re: [SQL] An unresolved performance problem. |