Re: Convert Min to string !!
> > That only works until 2096. You've set him up for a Y2.1K problem. > > Oh come now these programs will never live that long! ;-)<HUGE GRIN> > > Actually it will work until 2099. I did say it wasn't tested, didn't I? True, 2099 is the last year in which it will work, not 2096. But, if it IS still in use at that time, some product liability lawyer will probably figure out a way to sue the great-grandchildren of whoever coded the thing in the first place. > OK OK, s/b: > if (((years % 4) == 0 && (years % 100) != 0) || (years % 400) == 0) That should take care of the lawyer. Hoping Y2K hasn't made everyone immune to a little levity. Mark Collins mcollins@us.dhl.com
Mark Collins wrote:
> > > That only works until 2096. You've set him up for a Y2.1K
> > > problem.
> >
> > Oh come now these programs will never live that long! ;-)<HUGE GRIN>
> >
> > Actually it will work until 2099. I did say it wasn't tested,
> > didn't I?
>
> True, 2099 is the last year in which it will work, not 2096. But,
> if it IS still in use at that time, some product liability lawyer
> will probably figure out a way to sue the great-grandchildren of
> whoever coded the thing in the first place.
>
> > OK OK, s/b:
> > if (((years % 4) == 0 && (years % 100) != 0) || (years % 400) == 0)
>
> That should take care of the lawyer.
>
> Hoping Y2K hasn't made everyone immune to a little levity.
No, but I'm missing at least two intervening messages between the
question:
} I have a long variable : x= 600 000 minute !!
} (Is computed from 1.1.1900)
} How kann i easy translate in string: "1999-06-13 25:52"
and the levity above. And I'm not sure how there's a problem with
Y2.1K in what seems to me like the obvious solution:
-- !!UNTESTED CODE!! --
CREATE PROCEDURE minutes_to_dtime(x INTEGER) RETURNING CHAR(16); DEFINE dt DATETIME YEAR TO MINUTE;
DEFINE rv CHAR(16);
LET dt = DATETIME(1900-01-01 00:00) YEAR TO MINUTE + x UNITS MINUTE;
LET rv = dt;
RETURN rv;
END PROCEDURE;
I'm actually not at all sure you can't simply write:
(DATETIME(1900-01-01 00:00) YEAR TO MINUTE + x UNITS MINUTE) || ''
And there isn't any user-level calculation of leap years in there,
thus sadly diminishing the chances of Mark's ghost being sued by
his great-grandchildren's lawyers.
--
Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net)
Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN
#include <disclaimer.h>
Jonathan Leffler wrote:
>
> Mark Collins wrote:
> > > > That only works until 2096. You've set him up for a Y2.1K
> > > > problem.
> > >
> > > Oh come now these programs will never live that long! ;-)<HUGE GRIN>
> > >
> > > Actually it will work until 2099. I did say it wasn't tested,
> > > didn't I?
> >
> > True, 2099 is the last year in which it will work, not 2096. But,
> > if it IS still in use at that time, some product liability lawyer
> > will probably figure out a way to sue the great-grandchildren of
> > whoever coded the thing in the first place.
> >
> > > OK OK, s/b:
> > > if (((years % 4) == 0 && (years % 100) != 0) || (years % 400) == 0)
> >
> > That should take care of the lawyer.
> >
> > Hoping Y2K hasn't made everyone immune to a little levity.
>
> No, but I'm missing at least two intervening messages between the
> question:
> } I have a long variable : x= 600 000 minute !!
> } (Is computed from 1.1.1900)
> } How kann i easy translate in string: "1999-06-13 25:52"
>
> and the levity above. And I'm not sure how there's a problem with
> Y2.1K in what seems to me like the obvious solution:
>
> -- !!UNTESTED CODE!! --
> CREATE PROCEDURE minutes_to_dtime(x INTEGER) RETURNING CHAR(16);> DEFINE dt DATETIME YEAR TO MINUTE;
> DEFINE rv CHAR(16);
> LET dt = DATETIME(1900-01-01 00:00) YEAR TO MINUTE + x UNITS MINUTE;
> LET rv = dt;
> RETURN rv;
> END PROCEDURE;
>
> I'm actually not at all sure you can't simply write:
>
> (DATETIME(1900-01-01 00:00) YEAR TO MINUTE + x UNITS MINUTE) || ''
>
> And there isn't any user-level calculation of leap years in there,
> thus sadly diminishing the chances of Mark's ghost being sued by
> his great-grandchildren's lawyers.
Oh, sure! Go and come up with an obvious and simple solution! Sheesh.
;-))
Art S. Kagel