
                          Debian Libmdate Manual
                          ----------------------

                       Sean Dwyer <ewe2@can.org.au>

                         version 0.0.5, 2000-11-6


-------------------------------------------------------------------------------


Abstract
--------

     Libmdate is a calendrical conversion and interface API for the Mdate
     family of interfaces.  It tries to be applicable to the range of
     possible toolkits which can use its input/output routines.  This
     manual describes Libmdate as implemented under the Debian GNU/Linux
     system, which is the reference implementation.


Copyright Notice
----------------

     Copyright (C)2000 The Mdate Development Team.

     This manual is free software; you may redistribute it and/or modify it
     under the terms of the GNU General Public License as published by the
     Free Software Foundation; either version 2, or (at your option) any
     later version.

     This is distributed in the hope that it will be useful, but _without
     any warranty_; without even the implied warranty of merchantability or
     fitness for a particular purpose.  See the GNU General Public License
     for more details.

     A copy of the GNU General Public License is available as
     `/usr/share/common-licenses/GPL' in the Debian GNU/Linux distribution
     or on the World Wide Web at http://www.gnu.org/copyleft/gpl.html.  You
     can also obtain it by writing to the Free Software Foundation Inc., 59
     Temple Place - Suite 330, Boston, MA 02111-1307, USA.


-------------------------------------------------------------------------------


Contents
--------

     1.        About this document

     2.        Overview

     3.        General Input/Output Syntax
     3.1.      Parsing Input
     3.1.1.         Input Specifications
     3.2.      Output Formats

     4.        The Mayan Calendar
     4.1.      The Long Count
     4.1.1.         Long Count Units
     4.1.2.         The Calendar Round
     4.2.      The Haab Calendar
     4.3.      The Tzolkin Calendar

     5.        Compilation and Installation
     5.1.      Correlation Notes
     5.2.      Internationalization
     5.3.      Required Files
     5.4.      Bugs and Errors

     6.        Libmdate C API
     6.1.      API Overview
     6.2.      Porting Concerns
     6.3.      Definitions and Constants
     6.4.      Internal Routines.
     6.5.      Conversion Routines
     6.6.      Validation Routines
     6.7.      Interface Routines
     6.8.      Unimplemented Functions

     7.        Future Directions

     A.        Version Information


-------------------------------------------------------------------------------


1. About this document
----------------------

     The latest copy of this document can be found at
     http://mdate.sourceforge.net/docs/.


-------------------------------------------------------------------------------


2. Overview
-----------

     Libmdate arises out of the efforts of the Mdate Development Team,
     based at http://mdate.sourceforge.net.  The current active members of
     the MDT are:

        * Project Admin: `Sean Dwyer' <ewe2@users.sourceforge.net>

        * Libmdate Implementor: `David Starner'
          <dvdeug@users.sourceforge.net>

        * Internationalization: `Matthias Bauer'
          <moeffju@users.sourceforge.net>

     Libmdate originated out of the original `mdate' command-line program's
     source module `mtools.c', and is designed to support both command-line
     and GUI interfaces.

     The original `mdate' was created in 1998 by Sean Dwyer to provide a
     freely-available and simple tool to display and correlate the Mayan
     Calendar with the Gregorian Calendar.  It is still, to my knowledge,
     the only freely-available C implementation available for Unix systems.


-------------------------------------------------------------------------------


3. General Input/Output Syntax
------------------------------

     Libmdate is designed to handle the needs of different interfaces in a
     generalised way.  It tries not to complicate the usage of a
     command-line tool over a GUI tool and vice-versa.  This is especially
     important in the areas of what is acceptable input, and uniform
     output.


3.1. Parsing Input
------------------

     Libmdate tries to take care of the low-level work on inputs.  This
     includes validation of input.  It does _not_ try to do the work of an
     interface e.g.  parsing an edit box, or a command-line, it only deals
     with what the interface has passed to it.

     Interfaces to Libmdate must satisfy the needs of the user above all.
     Libmdate was designed with the desires of users to do two simple
     things: get the current date in Mayan calendar format, and be able to
     input dates of their own.  It is an interface's job to provide that
     access, and often unfortunately, catch all a user's mistakes.

     Here are some suggestions as to the plan of an interface to Libmdate.
     They apply equally to event-driven programs as to any standard date
     utility.

     _Always provide the current date._
          You don't have to output all the fields available, of course.
          The WinMdate port (Win9x) does this quite well with a tooltip.
          And it's trivial to implement as a starting-point.

     _Keep "mdate" in the program name._
          With all the interfaces abounding in the Unix world particularly,
          this can ensure that users can find _your_ interface.

     _Test input and provide error messages._
          Libmdate provides simple boolean functions to test validity of a
          date, as simple as an if test.  You must provide your own error
          messages, because Libmdate does not currently support
          internationalization, but this is an area we are working on.

     _Provide simple formatted output._
          Libmdate provides string output formats that you can retrieve
          from string buffers.  Graphics would be nice, but that's beyond
          the scope of Libmdate currently.

     _Provide useful help._
          You must also provide useful help and version functions.  This is
          good for everyone.

3.1.1. Input Specifications
---------------------------

     Libmdate expects and processes date inputs in the following forms:

        * _Gregorian Date_ `dd mm [+|-]yyyy'
          where _dd mm yyyy_ are numerical digits representing day month
          and a BC or AD year.
          Command-line example:
               isaac:ewe2:~$ mdate -d 13 08 -3113
               
               Gregorian Date          : 13-August--3113 (13/08/-3113)
               Julian Day Number       : 584285.0
               Long Count              : 00.00.00.00.00
               Tzolkin Date            : 4 Ahau
               Haab Date               : 8 Cumku
        * _Julian Day Number_ `nnnnnnnnn[.0]'
          where _nnnnnnnnn[.0]_ represents up to a nine-digit JDN,
          optionally with a decimal point.  Libmdate does not accept any
          real decimal fractions, so the decimal point can safely be left
          off.
          Command-line example:
               isaac:ewe2:~$ mdate -j 584285
               
               Gregorian Date          : 13-August--3113 (13/08/-3113)
               Julian Day Number       : 584285.0
               Long Count              : 00.00.00.00.00
               Tzolkin Date            : 4 Ahau
               Haab Date               : 8 Cumku
        * _Long Count_ `nn nn nn nn nn'
          where _nn nn nn nn nn_ represents a five-digit space-seperated
          Long Count date.
          Command-line example:
               isaac:ewe2:~$ mdate -l 00 00 00 00 00
               
               Gregorian Date          : 13-August--3113 (13/08/-3113)
               Julian Day Number       : 584285.0
               Long Count              : 00.00.00.00.00
               Tzolkin Date            : 4 Ahau
               Haab Date               : 8 Cumku

     Note that there is no input allowed for Tzolkin and Haab dates, with
     good reason.  Due to the interlocking and cyclic nature of the Mayan
     calendrical system, it is pointless to specify a Tzolkin and/or Haab
     date and get a unique Long Count, JDN, or Gregorian date.  There are
     methods for finding a range for which particular combinations of
     Tzolkin/Haab dates might apply to a date, but they involve different
     periodic components of Mayan astronomical science which are not
     directly connected to the calendar.  For more background, see Chapter
     4, `The Mayan Calendar'.


3.2. Output Formats
-------------------

     Libmdate is responsible for the output of its various functions.
     Rather than try to deal with the various typographies of the Mayan
     Calendar throughout its history, we have settled on the most standard
     spellings of the sacred and secular calendars.  Neither does it
     attempt to be a comprehensive solution for all possible Mayan
     astronomical/calendrical components.

     Libmdate simply outputs the Gregorian date, the Julian Day Number, the
     Long Count and the Haab and Tzolkin day/months.  At its simplest, you
     can output the Long Count and the Haab/Tzolkin dates - the Win9x
     interface port does this as a tooltip when iconfied.

     Different interfaces have different requirements: the command-line
     tool has a one-line output of all dates suitable for use by other
     programs; tkmdate uses this `program-parseable' form.  The
     command-line interface also has a list format, and the current GTK+
     interface seperates this into edit boxes.  The Libmdate API allows you
     to define your own way of outputting the date fields.  See Section
     6.7, `Interface Routines' for more details.


-------------------------------------------------------------------------------


4. The Mayan Calendar
---------------------

     The Mayan calendar is a combination of three calendars, the solar
     (Haab) and sacred (Tzolkin), and a more general day count (Long
     Count).  The Maya used a vigesimal (base 20) number system, and based
     on their astronomical observations (particularly of Venus) and their
     religious beliefs, were attracted to particular mathematical
     properties of planetary cycles: 13, 20, 60, 260, 360 were very popular
     numbers.

     The properties of these numbers led to a interestingly complex
     mathematical relationship between their calendars.  For instance, the
     Tzolkin calendar's cycle is predictable because the numbers 20 and 13
     are relatively prime (a fact very handy in other calculations).  This
     relationship with the Haab calendar incidentally is what makes it
     impossible to take a Tzolkin/Haab combination and pin it to a unique
     Long Count date.  This difficulty itself led to using the JDN to
     synchronise Western and Mayan calendars in the first place.

     All Mayan names in this guide are the standard nomeclature, although
     the newer Mayan standard for names is quickly overtaking it.


4.1. The Long Count
-------------------

     The Mayan Long Count is essentially a structured count of days between
     one epoch (reckoned in baktuns) and another.  There are various
     subunits associated with the Long Count detailed below.

4.1.1. Long Count Units
-----------------------

     The basic units of the Long Count are:
        * 1 kin = 1 day
        * 1 unial = 20 kin (20 days)
        * 1 tun = 18 unial (360 days)
        * 1 katun = 20 tun (7200 days)
        * 1 baktun = 20 katun (144,000 days)

     For example, a Gregorian date (23rd, March 2000) is 12.19.07.01.02 or
     12 baktun, 19 katun, 7 tun, 1 uinal and 2 kin.

     There are several larger units, of which the pictun (20 baktun or
     2,880,000 days) is the only unit of major interest, since it forms the
     most important epoch of which this current baktun is the 20th and
     last.  The end of this baktun (22nd December, 2012) ends this epoch,
     and according to the Maya, this world!  It will have taken 7885 solar
     years to come to pass.

4.1.2. The Calendar Round
-------------------------

     An important subunit of Mayan day counting is the Calendar Round,
     abbreviated CR.  This refers to a cycle upon which the same
     combination of Haab and Tzolkin calendars on a particular date returns
     (actually the least common multiple of 365 x 260 days), every 18,980
     days or about 52 solar years.

     This cycle is important, because it helps to check calculations from
     the epoch (0.0.0.0.0 4 Ahau 8 Cumku) by each CR.  It also is vital in
     any estimate of days elapsed between particular Haab/Tzolkin date
     combinations.  Combined with accurate Long Count references, this is
     the best way to back-check particular subperiods in Mayan history
     without reference to other more ceremonial cycles.


4.2. The Haab Calendar
----------------------

     The Haab, or solar calendar, is made up of 18 months of 20 days each
     (360 days), and 5 _unlucky_ days, called Uayeb.  All dates in each
     month were numbered from 0 to 19, with days in Uayeb numbered 0 to 4.

     The month names are:

          1. Pop   6.  Xul     11. Zac     16. Pax
          2. Uo    7.  Yaxkin  12. Ceh     17. Kayab
          3. Zip   8.  Mol     13. Mac     18. Cumku
          4. Zotz  9.  Chen    14. Kankin  19. Uayeb (5 days)
          5. Tzec  10. Yax     15. Muan


4.3. The Tzolkin Calendar
-------------------------

     The Tzolkin, or sacred calendar, consisted of 260 days made up of two
     cycles: a 13 day count and a 20 name count.  Each day in the 260 day
     year is thus unique, as both counts are simultaneous.  For example,
     after 13 Kan comes 1 Chicchan.  This fact, combined with the Haab
     calendar guarantees that in any given year, only @emph{four}
     particular dates are possible.  This is very helpful in tracking
     particular years, using the Calendar Round.

     The Tzolkin month names are:

          1. Imix     6.  Cimi   11. Chuen  16. Cib
          2. Ik       7.  Manik  12. Eb     17. Caban
          3. Akbal    8.  Lamat  13. Ben    18. Etznab
          4. Kan      9.  Muluc  14. Ix     19. Cauac
          5. Chicchan 10. Oc     15. Men    20. Ahau

     Taking 04 Ahau 08 Cumku as the starting date of the current epoch,
     adding 18,980 days (one Calendar Round) each time will return to 04
     Ahau 08 Cumku.  The next epoch cycles through 04 Ahau 03 Kankin.

     In fact, if you take the trouble to add 365 days successively to the
     starting date (best done by adding to the JDN), you can see the
     Tzolkin days cycle through 4 specific date names (but NOT numbers)
     against the same date 08 Cumku: Ahau, Chicchan, Oc and Men.  The
     numbers actually accumulate over that course.


-------------------------------------------------------------------------------


5. Compilation and Installation
-------------------------------


5.1. Correlation Notes
----------------------

     There is much academic argument about the correct correlation between
     the Gregorian and Mayan calendars.  For years, the
     _Goodman-Martinez-Thompson_ (G-M-T) correlation has been a standard,
     but the problems associated with it and evidence from surviving Mayan
     relics have diminished its stature.

     I have seen programs supporting more than five correlations.  The
     correlation used by default in Mdate is the "corrected" G-M-T from
     astronomical and Mayan records.

     In essence, there are two problems: the Julian Day Number system
     itself, and what constitutes a valid Mayan date to be compared with.

     The JDN system is known to have errors in its initial calculation,
     which puts some correlations out by as much as two or three days.  The
     Mayan system itself, while incredibly accurate, does "lose time" over
     long periods.  It is conjectured that the Maya themselves knew this
     and actually corrected their calendar based on their superb
     astronomical observations.  Relics believed to confirm this have been
     found, and _corrected G-M-T_ is one result.

     Without neither attempting to reform the JDN system for the purposes
     of a Mayan calendar program, nor ignore what are valid Mayan records,
     the correlation used for Mdate is, I feel, the best compromise.  The
     debate still rages on and _G-M-T_ and _corrected G-M-T_ are the two
     main camps.

     _corrected G-M-T_ is defined as `JDN_CORRELATION 584285.0L', and
     _standard G-M-T_ would be `JDN_CORRELATION 584282.0L' in Mdate's code,
     a difference of about three days.  However, _corrected G-M-T_ is
     accurate as far as the _end_ of the epoch, 22nd December, 2012.

     if you prefer the _standard G-M-T_, you should redefine the macro in
     your _own_ code rather than `mdate.h', for example:

          #include <mdate.h>
          /* redefine for standard G-M-T */
          #ifdef JDN_CORRELATION
          	#undef JDN_CORRELATION
          	#define JDN_CORRELATION 584282.0L
          #endif /* JDN_CORRELATION */


5.2. Internationalization
-------------------------

     Mdate is intended to used all over the world and includes
     internationalization support.  This is where Libmdate differs, because
     it avoids error messages themselves, preferring to deal with the math.

     If this were a perfect world, we could be assured that multibyte
     compatibility could be implemented into libmdate, and make life a
     little simpler for interface developers, but we haven't got there yet,
     sorry.


5.3. Required Files
-------------------

     Libmdate prefers a GNU system, although hopefully the configure script
     can take care of most things.  See Section 6.2, `Porting Concerns'.


5.4. Bugs and Errors
--------------------

     There _will_ be bugs - please report any to:

     Sean Dwyer <ewe2@users.sourceforge.net>

     or to any of the Mdate Development Team at
     http://mdate.sourceforge.net.  Please check this URL regularly as the
     site does get updated.  You can also use the bugs interface for
     convenience at the Project Page
     (http://sourceforge.net/project/?group_id=2730).


-------------------------------------------------------------------------------


6. Libmdate C API
-----------------

     This chapter is always being revised as Libmdate is updated.  We hope
     the API is useful to programmers.


6.1. API Overview
-----------------

     As an ongoing project, Libmdate is often checked for usefulness.  The
     API itself is accessible from `<mdate.h>', although there are many
     as-yet unimplemented functions in that interface.  We are unsure of
     the usefulness of some functions, and want feedback from developers!

     This chapter is a general description of Libmdate up to version 0.0.5.
     The next version is likely to be a major overhaul, as new
     compatibility hopefully exposes problems on different architectures.

     Libmdate is basically a math-based calendar conversion library, with
     some interface helper functions.  The crucial conversion factor (as in
     many other calendar-related utilities) is the Julian Day Number
     (_JDN_).  Libmdate uses a rounded JDN, omitting the standard
     astronomical fraction, but retaining the JDN's decimal character.
     This is because the Mayan Calendar counts days as starting at
     midnight, rather than noon.

     In the following sections, values that are global defines are classed
     as a _Define_.  All functions, constants and definitions discussed
     below are defined in `<mdate.h>'.  Internal functions or macros aren't
     discussed unless they affect portability and implementation.


6.2. Porting Concerns
---------------------

     There are several system-dependent functions used by Libmdate: most
     GNU-based systems, or systems with access to a GNU compiler shouldn't
     have any trouble with them.  Of particular concern are those systems
     lacking `drem()' and `snprintf()'.

     _System Function_ _double drem (double_ _x__, double_ _y__)_
          `drem()' is a BSD-derived maths function, which is IEEE 754 and
          854 specification compliant.  In recent versions of AIX and HPUX,
          `drem()' has been replaced by `remainder()'.  This is not to be
          confused with the GNU implementation of `remainder()' as an
          X/OPEN standard maths function.  GNU implements `drem()' as an
          inline assembly function which uses an IEEE-specific
          floating-point instruction (`fprem1') to return the remainder of
          a floating-point modulus regardless of sign, in contrast to the
          standard `fmod()' call.  Its use in Libmdate is to avoid
          side-effects of the calculation of Julian Day Numbers.

     _System Function_ _size_t strftime (char_ `*string'_, size_t_ `max'_,
     const char_ `*format'_, const struct tm_ `*tm'_)_
          `strftime' formats the data from `struct tm' and puts it into the
          array `*string'.  As this function is generally ANSI C compliant,
          may systems will already have it.

     _System Function_ _int snprintf (char_ `*string'_, size_t_ `n'_, const
     char_ `*format'_, ... )_
          This is a GNU-specific function that takes a variable number of
          arguments and copies them to `*string' according to `*format' up
          to at least `n' characters.  `n' for Libmdate is at least 256
          characters.

     To address these portability concerns, Libmdate 0.0.5 has recently
     added support for `remainder()' and introduces an internal
     compatibility function, `double my_drem (double, double)', which is
     selected on configuration of Libmdate on systems which need it.

     We will add the remaining functions mentioned above for those who need
     them in a future version of Libmdate.


6.3. Definitions and Constants
------------------------------

     _Define_ `JDN_CORRELATION' _long integer_
          Defines the default correlation for all date conversions in
          Libmdate.  `JDN_CORRELATION', although defined as a long integer,
          is really treated as a double in all conversions.

     _Typedef_ `double julian_date'
          To be certain that julian_date is always treated as a double.

     _Typedef_ `enum {false, true} BOOL'
          A necessary typedef.  The `BOOL' typdef enables certain functions
          to return a boolean value in a way that is not system-specific.
          Although recent C/C++ compilers support the `bool' data type, it
          is unwise to expect it by default.

     The basic data types used by Libmdate are integrated structures from
     which functions get data to to which they return values.

     _Structure_ _struct long_count {int_ `bak'_, int_ `kat'_, int_ `tun'_,
     int_ `uin'_, int_ `kin' _};_
          The Long Count data type.

     _Structure_ _struct greg_date {int_ `day'_, int_ `month'_, int_ `year'
     _};_
          The Gregorian Calendar data type.

     _Structure_ _struct tzolkin_date {int_ `month'_, int_ `day' _};_
          The Tzolkin Calendar data type.

     _Structure_ _struct haab_date {int_ `month'_, int_ `day' _};_
          The Haab Calendar data type.


6.4. Internal Routines.
-----------------------

     Internal routines within Libmdate.  You will never need to use these
     directly, and they're not exposed in the public interface.

     _Function_ _static double my_mod (double_ `x', _double_ `y' _)_
          Performs an accurate modulus on any combination of signed
          double-precision numbers.  It is a combination of `fmod()' and
          `drem()' calls, and depending on the system's lack of `drem()',
          `remainder()' or `my_drem()' calls.

     _Function_ _static int gregorian_leap_year (int_ `g_date' _)_
          Tests a given Gregorian date for leap years.  Called from
          `is_valid_greg_date()' .

     _Function_ _static double my_drem (double_ `x', _double_ `y' _)_
          C implementation of `drem()', for compatibility on systems
          lacking any alternative.


6.5. Conversion Routines
------------------------

     These are the currently implemented public conversion functions.  They
     not only convert input, they also validate input, so you can use their
     return value to return errors.  Mostly you'll only need to check the
     return values of the jdate, greg_date, and long_count functions.  The
     Tzolkin and Haab calendar conversions depend on those functions, and
     never need error-checking.

     _Function_ _BOOL jdate_from_greg_date (struct greg_date_ `from',
     _struct julian_date_ `*to' _)_
          Calculates a JDN from a Gregorian date.

     _Function_ _BOOL jdate_from_long_count (struct long_count_ `from',
     _struct julian_date_ `*to' _)_
          Calculates a JDN from a Long Count.

     _Function_ _BOOL jdate_from_tm (struct tm_ `from', _struct
     julian_date_ `*to' _)_
          Calculates a JDN from the current date in `struct tm'.

     _Function_ _BOOL greg_date_from_jdate (struct julian_date_ `from',
     _struct greg_date_ `*to' _)_
          Calculates a Gregorian date from a JDN.

     _Function_ _BOOL haab_date_from_jdate (struct julian_date_ `from',
     _struct haab_date_ `*to' _)_
          Calculates a Haab date from a JDN.

     _Function_ _BOOL tzolkin_date_from_jdate (struct julian_date_ `from'
     _struct tzolkin_date_ `*to' _)_
          Calculates a Tzolkin date from a JDN.

     _Function_ _BOOL long_count_from_jdate (struct julian_date_ `from',
     _struct long_count_ `*to' _)_
          Calculates a Long Count from a JDN.


6.6. Validation Routines
------------------------

     Currently implemented validation routines.  These are mostly for
     internal use, and don't need to be called from an interface unless
     you're doing something unusual.  The is_valid functions probably
     should disappear from public view, but `jdate_from_double_jd()' is
     more strictly an interface routine.

     _Function_ _BOOL is_valid_jdate (double_ `jul' _)_
          Bounds checking of JDN's.  Prevents input accessing dates before
          the JDN epoch, which matches Long Count 0.0.0.0.0 .

     _Function_ _BOOL is_valid_greg_date (struct greg_date_ `date' _)_
          Bounds checking of Gregorian dates.

     _Function_ _BOOL jdate_from_double_jd (double_ `from',_struct
     julian_date_ `*to' _)_
          Tests a JDN and ensures it remains a double-precision number.


6.7. Interface Routines
-----------------------

     These are the currently implemented public interface routines.
     They're mostly concerned with input and output formatting, and only
     return a value if there's a serious error (such as a problem with the
     interface itself!).

     _Function_ _void jdate_to_str (struct julian_date_ `from',_char_ `*to'
     _)_
          Copies the current value of `struct julian_date' to a string
          buffer.

     _Function_ _void greg_date_to_str (struct greg_date_ `from', _char_
     `*to' _)_
          Copies the current values of `struct greg_date' to a string
          buffer.

     _Function_ _void long_count_to str (struct long_count_ `from', _char_
     `*to' _)_
          Copies the current values of `struct long_count' to a string
          buffer.

     _Function_ _BOOL haab_date_to_str (struct haab_date_ `from', _char_
     `*to' _)_
          Copies the current values of `struct haab_date' to a string
          buffer.

     _Function_ _BOOL haab_month_to_str (int_ `from', _char_ `*to' _)_
          Copies the current value of a Haab month to a string buffer.

     _Function_ _BOOL tzolkin_date_to_str (struct tzolkin_date_ `from',
     _char_ `*to' _)_
          Copies the current values of `struct tzolkin_date' to a string
          buffer.

     _Function_ _BOOL tzolkin_month_to_str (int_ `from', _char_ `*to' _)_
          Copies the current value of a Tzolkin month to a string buffer.


6.8. Unimplemented Functions
----------------------------

     Although these functions are listed in the public interface, they are
     as yet unimplemented as they dont have any bearing on current needs,
     but may be added for the sake of completeness.  If you need one of
     these functions, tell us!  Possible applications could be extending
     the range of Mayan calendar dates to before the JDN epoch, extending
     JDN's to their true astronomical values (difficult if using the Unix
     epoch-related functions), or extra consistency checking.

     One function that has not yet been implemented, but would probably be
     of great use, is a standard function to fill the structures for the
     current date.  This is currently implemented at interface-level, and
     would be trivial to code.  It could perhaps use some of the below
     functions for sanity checking.

     _Function_ _jdate_from_time_t (time_t_ `from', _struct julian_date_
     `*to' _)_
          Construct a JDN from `time_t' seconds since the Unix epoch.

     _Function_ _is_valid_struct_tm (struct tm_ `date' _)_
          Check `struct tm' for consistency.

     _Function_ _is_valid_long_count (struct long_count_ `date' _)_
          Check a Long Count for consistency.  Perhaps useful for checking
          impossible numbers, or allow dates before the JDN epoch to be
          input.

     _Function_ _tm_from_jdate (struct julian_date_ `from' _struct tm_ `to'
     _)_
          The hypothetical opposite of `jdate_from_tm()'.

     _Function_ _time_t_from_jdate (struct julian_date_ `from', _time_t_
     `*to' _)_
          Get `time_t' seconds since the Unix Epoch from a JDN.


-------------------------------------------------------------------------------


7. Future Directions
--------------------

     With the exception of implementing the unfinished functions, future
     directions for Libmdate include further compatibility enhancements, a
     more inclusive error API to cut down on interface coding, possibly
     some of the more esoteric aspects of Mayan calendars.

     A big wish is greater internationalization support.  At present, we
     only have two translations at interface-level, but if the translation
     support were greater, it would make an effort at internalizing the
     NLS/i18n support more urgent.  The Qt libraries are way ahead of
     everyone in this field, for example.

     If you're interested in furthering any of these goals, _PLEASE_ join
     us at http://mdate.sourceforge.net/ or email me at
     <ewe2@users.sourceforge.net>!!  Thanks for your interest so far, and
     thank you for reading!


-------------------------------------------------------------------------------


A. Version Information
----------------------

     _0.0.4a_
          First texinfo version of the Libmdate Documentation.
     _0.0.5_
          First DebianDoc DTD formatted text source.


-------------------------------------------------------------------------------


     Debian Libmdate Manual

     Sean Dwyer <ewe2@can.org.au>

     version 0.0.5, 2000-11-6

