>>>>> "Mark-Jason" == Mark-Jason Dominus <mjd@stripped> writes:
>> Although the traditional return type of time is long, the value
>> returned is usually of type unsigned long. The ANSI C version
>> of time allows the return type, time_t, to be any arithmetic type.
Mark-Jason> You are reading the description of the `time' function, which returns
Mark-Jason> the current calendar time. Since it returns the current time, *of
Mark-Jason> course* the value is `usually' positive. Nevertheless, as I said, the
Mark-Jason> type has traditionally been a signed value. That is why we are going
Mark-Jason> to have a Y2038 problem instead of a Y2106 problem.
I am pretty sure that before Y2038 we will all be using unsigned 32
or signed 64 bit values in our programs. 32 bits will still be
popular because if you have MUCH dates, this will always make a
significant saving even if you by then have 8T RAM in every home
>> I light of this, I don't think the use of the term "defect" is
>> appropriate in this case.
Mark-Jason> Fine; I withdraw the word `defect'. The only really interesting
Mark-Jason> question is whether or not the maintainers of MySQL will accept a
Mark-Jason> patch. I would like to provide one, but since the discussion seems to
Mark-Jason> indicate that this is considered a feature for some inexplicable
Mark-Jason> reason, I don't want to risk the time and effort unless someone can
Mark-Jason> reassure me that the patch will be accepted.
I would prefer to have timestamp to work until 2106 instead of before
Mark-Jason> If someone who can accept a patch would like to contact me, I would be
Mark-Jason> delighted to try to provide one. Unless that happens, more discussion
Mark-Jason> will probably not be productive.
If you can be (almost) 100 % sure that the patch will work on all systems and
you can do it with #ifdefs so that the user can decide if he wants the
current behaveour (waiting for Y2106 to work) or your behaveour we will
accept the patch (as long as it is relatively clean).