QuickPage Year-2000 Statement

We are quite confident that all of our systems are Year 2000 Compliant. However, we have over a two year backlog of Year 2000 Compliance forms to fill out, so according to our scheduling database, you should hear back from us in June, 1900.     -- usenet, 1998

Seriously though, the Y2K issue is a big concern among users, system administrators, and managers. As hard as we all try to ensure things will go smoothly in the next millennium, bugs still occasionally slip through. I am aware of two Y2K bugs in QuickPage v3.2, both of which are related to the -a command-line option.

SNPP allows a client to submit pages to a server with "hold" times. That is, the client can tell the server not to actually deliver the page until a specified time. QuickPage fully supports this feature. However, the protocol requires time to be represented in the ASCII format YYMMDDHHMMSS. Specifically, the year is represented with only two digits. QuickPage attempts to work around this protocol limitation by using the following algorithm:

IF the last two digits of the current year are 50 or greater AND the specified two-digit year is less than 50, THEN assume the specified year is for the next century, ELSE assume the specified year is for the current century.

However, there are two implementation bugs in v3.2 which prevent this from working as desired:

Both of these bugs are fixed in QuickPage v3.3 (a beta version is now available). No other Y2K bugs have been reported. With the exception of the ASCII format used by the client to represent a hold time to the server over the wire, all times are stored internally using the operating system's native representation. On most systems this is a 32-bit integer (time_t) representing the number of seconds since 1 January, 1970.