>>> Are you sure that it is 190 ? Not 100 ? The latter would be easy
>>> to explain with "struct tm". It has a member tm_year that is
>>> often mistakingly taken as representing the year and decade as a
>>> two digit number when it actually is years since 1900 (see man
>>> mktime). The fix would be to get two digits with (tm.tm_year %
>>> 100) or better the correct year with (tm.tm_year + 1900).
>> That 190 is almost certainly correct - I would imagine the
>> relevant code looks something like the following:
>> Q> printf( "%02u.%02u.19%u", tm_mday, tm_mon, tm_year % 100 );
> Aah, ok, well that would explain the 190. However that would be
> somewhat... err... funny coding. The coder knows that tm_year
> can be > 99 but doesn't realise that if it really is, it means
> the century has changed...
Alternatively, the programmer didn't realise that tm_year didn't
contain the century, and just did the "% 100" bit to strip the century
digits from the year...
>> Try it, and you'll see you get just that for a date of 1st Jan
>> 2000, and the fix would be to use the following instead:
>> Q> printf( "%02u.%02u.%u", tm_mday, tm_mon, tm_year + 1900 );
> Yes. Just like I said above.
Precicely...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html