[MacPerl] Re:

[Terje Bless <link@tss.no>]

Kevin van Haaren wrote:

> My other assertion also is true:
> It doesn't matter what the OS does, the programmer has to be aware of y2k
> problems also.  Simply using the internal functions won't help you if you
> are pulling in just 2 digit years (from whatever source), you have to make
> an assumption of what the other 2-digits are.  Of course if you have the
> option store the date/time as a mm/dd/yyyy format.

Well, the important thing is to know what you are doing.

_____
%perldoc -f time
=item time

Returns the number of non-leap seconds since whatever time the system
considers to be the epoch (that's 00:00:00, January 1, 1904 for MacOS,
and 00:00:00 UTC, January 1, 1970 for most other systems).
Suitable for feeding to gmtime() and localtime().

%perldoc -f localtime
=item localtime EXPR

Converts a time as returned by the time function to a 9-element array
with the time analyzed for the local time zone.  Typically used as
follows:

    #  0    1    2     3     4    5     6     7     8
    ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
                                                localtime(time);

All array elements are numeric, and come straight out of a struct tm.
In particular this means that $mon has the range 0..11 and $wday has
the range 0..6 with sunday as day 0.  **Also, $year is the number of
years since 1900, that is, $year is 123 in year 2023.** [my emphasis]
_____

You never /assume/ what the value is. You *know* what it is because the
function is defined to return the number of years since 1900. If you
want to be Y2K safe you just make sure you never do
  $Year = "19" . (localtime(time))[5];
but rather do
  $Year = 1900 + (localtime(time))[5];

If you /assume/ something that involves localtime() allways returning
two digits then you`ve made a false assumption and should check the docs
to see what it *really* returns. Perl is Y2K safe; not all programmers
are.


>So my warning is this:
>Just because you're on a mac don't assume you're y2k proof.

To quote the only good line in Under Siege II:
    "Assumption, is the Mother of all fuckups!" :-)


>If you have a program that takes years in 2-digits (whatever OS,
>whatever program) or ouputs years in 2 digits you may have a problem.

Not at all. Or rather, sure you /may/ have a problem, but you /may/ have
a problem even if you use 4, 5 or 6 digit years. The year returned from
localtime() is a typical snafu in Perl, but this not a problem with Perl
but with the sloppy work of those that use it wrong. Using 4 digit years
wrong will also cause problems. I`ve actually seen code that increments
from 0 to 1999 and then flips over to 0 again; in Perl!

The important thing is to /know/ *not* /assume/.


>Is this being blown way out of proportion in the media - yes.  Will the end
>of the world as we know it come about - no.  If you're writing programs,
>use 4-digit years (of couse you could use a 5 digit year and claim that you
>are year 10k proof!).  If you use programs watch for 2-digit dates and
>figure out if its important.

The Y2K problem is serious, but it`s caused by bad design. Bad design is
to
be avoided. This holds true for the MS-DOS 640K; HFS max file-size & max
allocation blocks; non-ASCII in email/news; etc. etc. etc. ad nauseum.
Y2K is only there because a whole generation of FORTRAN programmers
didn`t
do things right and passed this bad habit on to the next generation(s).

This is the same thing that causes the occational stripping of 8bit
characters in email and what made MIME/QP necessary. Though in that
case it was `merkins that didn`t take the rest of the world into
account.

A more serious problem is the year 2038 problem. :-)

-- 
Party? Party, lord? Yes, lord. Right away, lord.
        - Beopunk Cyberwulf

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch