Tweak alf man page.

1 files changed, 10 insertions, 7 deletions

diff --git a/src/alf.rst b/src/alf.rst
index 5d6114a..32a2cd3 100644
--- a/src/alf.rst
+++ b/src/alf.rst
@@ -218,16 +218,17 @@ a DOS capable of handling multi-megabyte files...
 Performance
 -----------
 
-Performance is pretty good, as of alftools-0.3.0. For small files
+Performance is pretty good, as of alftools-0.4.0. For small files
 like you'd use on an Atari (up to 50KB), it's basically instantaneous
-(0.008 seconds) on the author's modest i7 workstation. For a 1MB
-text file, it takes 0.026 sec; for 1MB of random garbage, it's 0.043
-sec (and the resulting ALF file is 36% larger than the garbage).
+(0.008 seconds) on the author's modest i7 workstation. For a 1MB text
+file, it takes 0.026 sec (faster than **arc**\!). For 1MB of random
+garbage, it's 0.043 sec (and the resulting ALF file is 36% larger than
+the garbage).
 
 By comparison, **zip** takes 0.06 seconds to compress the 1MB text file,
 and 0.03 sec for the 1MB randomness (and the compressed file is still
-larger than the input, but only by 312 bytes). The speed demon is **arc**\:
-it compresses the text file in 0.03s, and it's smart enough to *not*
+larger than the input, but only by 312 bytes). **arc**
+compresses the text file in 0.03s, and it's smart enough to *not*
 compress the random garbage (it uses the 'store' method, which **alf**
 doesn't have).
 
@@ -241,7 +242,9 @@ options above). There's no way to store timezone or daylight savings
 info in the *ALF* file.
 
 The year stored in the *ALF* file doesn't have a Y2K problem. It does,
-however, have a Y2108 problem: the range is from 1980 to 2107.
+however, have a Y2108 problem: the range is from 1980 to 2107. Files
+with timestamps outside this range will have a zero (invalid) date in the
+*ALF* header, and **unalf** will display the date as *<none>*.
 
 The timestamp only has 2-second resolution. Files with odd-numbered
 seconds in the *mtime* will have the number before that (1 => 0, 31 =>