If you're defining numeric codes that mean season, you might consider
using the well-established and widely used MARC codes that were defined
for this purpose (for designating publication patterns of journals:
21 - Spring
22 - Summer
23 - Autumn
24 - Winter
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^ Rebecca S. Guenther ^^
^^ Senior Networking and Standards Specialist ^^
^^ Network Development and MARC Standards Office ^^
^^ 1st and Independence Ave. SE ^^
^^ Library of Congress ^^
^^ Washington, DC 20540-4402 ^^
^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^
^^ [log in to unmask] ^^
^^ ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Date: Tue, 19 Dec 2000 17:14:00 -0600
> From: Andrew Koebrick <[log in to unmask]>
> Subject: Re: ISO date; introduction
>
> Greetings,
>
> Many thanks to the folks who advised on adapting ISO-8601 to accommodate =
> seasonal date declarations. Thanks also to Eileen Quam for passing along =
> my request to this list. As I will be developing a few intranet/ web =
> publishing applications based (loosely) on DC over the next few months, I =
> though it wise to subscribe to this group myself and eavesdrop on the =
> development of the standard.
>
> For those interested, here is the tweak I will using to "solve" the =
> ISO-8601/Season issue as it pertains to the citation database I am =
> building:
>
> Seasons, quarters, and multiple-month declarations (i..e January-February) =
> will be mapped to the "day" number space, using digits above 31. For =
> example:
>
> "Winter 2000" becomes "2000-12-35"
> "Fourth Quarter" becomes "2000-10-40"...
>
> Translation from these corrupted ISO dates to the intended string is =
> accomplished via a quicky Perl subroutine at the time of database =
> retrieval/display. Date creations are done with drop down menus to limit =
> the need for the data-entry people to understand the mapping.=20
>
> If anyone is interested in using or critiquing it, I have posted the =
> subroutine code at: ftp://www.mnplan.state.mn.us/pub/date_swap.pl=20
>
> I would be particularly interested in hearing if anyone with more =
> experience in this area can predict problems with this workaround which =
> may plague me in future years.
>
> Cheers,
>
> Andrew Koebrick
> Web Coordinator/Librarian
> MN-Planning (Office of Strategic and Long Range Planning)
> 658 Cedar St., Suite 300
> St. Paul, MN 55155
>
> 651-296-4156 phone
> 651-296-3698 fax
>
> "Whenever I see an adult on a bicycle I no longer despair for the human =
> race." -- H.G. Wells
>
> www.mnplan.state.mn.us
>
> ------------------------------
>
> End of DC-GENERAL Digest - 18 Dec 2000 to 19 Dec 2000 (#2000-10)
> ****************************************************************
>
|