Thread: BUG #6028: age() function output contracts "months", but not any other units.

The following bug has been logged online:

Bug reference:      6028
Logged by:          Martin A. Brooks
Email address:      martin@antibodyMX.net
PostgreSQL version: 9.0.4
Operating system:   Debian/GNU Linux 6
Description:        age() function output contracts "months", but not any
other units.
Details:

Hi

postgres=# select age(now(),'1973-12-20'::timestamp);
                   age
-----------------------------------------
 37 years 4 mons 28 days 15:33:49.041831
(1 row)


Note "mons" and not "months".  And if "mons", why not "yrs" and "dys"?

Regards

Martin A. Brooks
http://antibodyMX.net/

Martin A. Brooks wrote:
>
> The following bug has been logged online:
>
> Bug reference:      6028
> Logged by:          Martin A. Brooks
> Email address:      martin@antibodyMX.net
> PostgreSQL version: 9.0.4
> Operating system:   Debian/GNU Linux 6
> Description:        age() function output contracts "months", but not any
> other units.
> Details:
>
> Hi
>
> postgres=# select age(now(),'1973-12-20'::timestamp);
>                    age
> -----------------------------------------
>  37 years 4 mons 28 days 15:33:49.041831
> (1 row)
>
>
> Note "mons" and not "months".  And 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.  I think
this code came from Berkeley.  My guess is that the spelling was based
on the libc struct tm field names:

           int tm_mday;    /* day of month (1 - 31) */
           int tm_mon;     /* month of year (0 - 11) */
           int tm_year;    /* 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.  :-|

Does anyone feel this is worth changing?  I am concerned such a change
would break many user applications.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

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

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, May 18, 2011 at 3:40 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> Does anyone feel this is worth changing?  I 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.

ISTM that changing interval's output formatting would create far too
many problems to be justifiable for such a purely cosmetic issue.

            regards, tom lane

"Martin A. Brooks" <martin@antibodymx.net> writes:
> On Mon, May 23, 2011 19:02, Tom Lane wrote:
>> ISTM that changing interval's output formatting would create far too
>> many problems to be justifiable for such a purely cosmetic issue.

> I almost entirely agree with you except....

> My current $dayjob is working in an industry where details and aesthetics
> are everything.  We will spend thousands of hours of processor time just
> to make sure than the sheen on an animal's fur will suggest "healthy and
> luxuriant" rather than "warm and moist".  It's about artistic polish.

> If people are agreeing that this is not the intended, desrired or
> specified output for this function, then make with the polish.  It isn't
> the first, and won't be the last, time that something has potentially
> broken compatibility in postgres.

I think possibly you misunderstand the scope of the breakage you're
proposing.  This is not about the age() function.  It's interval_out()
that's at stake, and so changing this would change the output formatting
for *every* operation that yields intervals.  That makes it pretty
high-risk.

            regards, tom lane

On Mon, May 23, 2011 19:50, Tom Lane wrote:
> I think possibly you misunderstand the scope of the breakage you're
> proposing.  This is not about the age() function.  It's interval_out()
> that's at stake, and so changing this would change the output formatting
> for *every* operation that yields intervals.  That makes it pretty
> high-risk.

I didn't, but now do, and can appreciate your caution.


Regards


Martin.

On Mon, May 23, 2011 19:02, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, May 18, 2011 at 3:40 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>> Does anyone feel this is worth changing?  I 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.
>
> ISTM that changing interval's output formatting would create far too
> many problems to be justifiable for such a purely cosmetic issue.

I almost entirely agree with you except....

My current $dayjob is working in an industry where details and aesthetics
are everything.  We will spend thousands of hours of processor time just
to make sure than the sheen on an animal's fur will suggest "healthy and
luxuriant" rather than "warm and moist".  It's about artistic polish.

If people are agreeing that this is not the intended, desrired or
specified output for this function, then make with the polish.  It isn't
the first, and won't be the last, time that something has potentially
broken compatibility in postgres.

EUR0.02

Regards

Martin.

"Martin A. Brooks" <martin@antibodymx.net> wrote:

> My current $dayjob is working in an industry where details and
> aesthetics are everything.  We will spend thousands of hours of
> processor time just to make sure than the sheen on an animal's fur
> will suggest "healthy and luxuriant" rather than "warm and moist".
> It's about artistic polish.
>
> If people are agreeing that this is not the intended, desrired or
> specified output for this function, then make with the polish.

Of course, you can always write your own function to output in as
polished a format as you would prefer, without breaking anything for
anyone else.

-Kevin