Fix rfc-1123 format documentation

Change +rfc-1123-format+ to use numeric timezone indicators

RFC-1123 section 5.2.14 writes

"There is a strong trend towards the use of numeric timezone
indicators, and implementations SHOULD use numeric timezones
instead of timezone names."

RFC-822 section 5.1 writes the syntax of timezone

zone        =  "UT"  / "GMT"                ; Universal Time
                                            ; North American : UT
            /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
            /  "CST" / "CDT"                ;  Central:  - 6/ - 5
            /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
            /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
            /  1ALPHA                       ; Military: Z = UT;
                                            ;  A:-1; (J not used)
                                            ;  M:-12; N:+1; Y:+12
            / ( ("+" / "-") 4DIGIT )        ; Local differential
                                            ;  hours+min. (HHMM)

Which I feel using the numeric is the way to go. It's always valid
that we don't have to worry about if the timezone abbreviation is in
the allowed list.

Patch to support Allegro Common Lisp

Fix a compilation warning on LispWorks

When a function is declared as `inline` on LispWorks, the definition must appear before it is used otherwise a warning is issued.

Allow the :HOUR12 format in format-timestring to take a padding and length argument.

Hello,

I have produced a patch which allows LOCAL-TIME to support subsecond
resolution of time in Allegro Common Lisp. I produced it with git
format-patch and attached it to this email.  Hopefully, it'll be good
enough without further changes. Let me know if you need anything else.

Thank you.

Peter Keller

>From ae6325f7aadaf771f6ed86ad7c4893818351031e Mon Sep 17 00:00:00 2001
From: Peter Keller <psilord@cs.wisc.edu>
Date: Fri, 31 Jan 2014 15:57:26 -0600
Subject: [PATCH] Add support for subsecond resolution under Allegro.

Refactor TRANSITION-POSITION to use iteration

Split +iso-8601-format+ into +iso-8601-date-format+ and +iso-8601-time-format+ so that they can be used individually.

Split +iso-8601-format+ into +iso-8601-date-format+ and +iso-8601-time-format+ so that they can be used individually.

Fix illegal usage of ftype declaration and update TODO

Using iterative function makes the tests run in 83% of the time of the
old recursive function.

(declaim (ftype (function * simple-base-string) foo)) is illegal,
and ecl failed with it.

Fixed minor typo in documentation

This should fix issue #15.

This was generating some warnings in sbcl and could cause more trouble
for other implementations.

Fixed bug in transition-position

Added test for local-time::transition-position

Fixed bug in transition-position causing it to select the incorrect position in the haystack for many cases.

Test Case:
(local-time::transition-position 13 #(-15 -10 -5 0 5 10 15 20 25 30 35 40 45 50 55 60))
==> 6

adjust-timestamp bugfix

previously, if a day-of-week adjustment was made into the following months,
an error was raised.

Abstract out the notion of clocks

Resolves issue #12

This addresses issue #11.

Fix issue with STRING subtypes.

Which allows (parse-timestring (format-timestring nil (now))) to work
again (tested on SBCL 1.1.6.12, CLISP 2.48) where it previously raised
an error on SBCL because FORMAT-TIMESTRING returns a SIMPLE-BASE-STRING:

debugger invoked on a TYPE-ERROR in thread
  The value "2013-04-16T23:44:28.910375+02:00"
  is not of type
    (SIMPLE-ARRAY CHARACTER (*)).

Since the UPGRADED-ARRAY-ELEMENT-TYPE for BASE-CHAR and CHARACTER may
differ, (SUBTYPEP 'SIMPLE-STRING '(SIMPLE-ARRAY CHARACTER (*))) can be
true or false between implementations, so %SPLIT-TIMESTRING has to
use SIMPLE-STRING (and CHARACTER).