On Wed, May 18, 2011 at 3:40 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Martin A. Brooks wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: =A0 =A0 =A06028
>> Logged by: =A0 =A0 =A0 =A0 =A0Martin A. Brooks
>> Email address: =A0 =A0 =A0martin@antibodyMX.net
>> PostgreSQL version: 9.0.4
>> Operating system: =A0 Debian/GNU Linux 6
>> Description: =A0 =A0 =A0 =A0age() function output contracts "months", bu=
t not any
>> other units.
>> Details:
>>
>> Hi
>>
>> postgres=3D# select age(now(),'1973-12-20'::timestamp);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0age
>> -----------------------------------------
>> =A037 years 4 mons 28 days 15:33:49.041831
>> (1 row)
>>
>>
>> Note "mons" and not "months". =A0And if "mons", why not "yrs" and "dys"?
>
> I was hoping someone else knew a good answer to this question, but now
> that no one replied --- I have no idea on it was done this way. =A0I think
> this code came from Berkeley. =A0My guess is that the spelling was based
> on the libc struct tm field names:
>
> =A0 =A0 =A0 =A0 =A0 int tm_mday; =A0 =A0/* day of month (1 - 31) */
> =A0 =A0 =A0 =A0 =A0 int tm_mon; =A0 =A0 /* month of year (0 - 11) */
> =A0 =A0 =A0 =A0 =A0 int tm_year; =A0 =A0/* year - 1900 */
>
> The only clear answer I can think of is that "month" has five letters,
> and "year" and "day" have less then five letters. =A0:-|
>
> Does anyone feel this is worth changing? =A0I am concerned such a change
> would break many user applications.
The backward compatibility problem is pretty icky, but I don't much
like the idea of leaving it as-is, either.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company