Updated: 2022/Sep/29

Please read Privacy Policy. It's for your privacy.

PARSEDATE(3)               Library Functions Manual               PARSEDATE(3)

     parsedate - date parsing function

     System Utilities Library (libutil, -lutil)

     #include <util.h>

     parsedate(const char *datestr, const time_t *time, const int *tzoff);

     The parsedate() function parses a date and time from datestr described in
     English relative to an optional time point, and an optional timezone
     offset (in minutes behind/west of UTC) specified in tzoff.  If time is
     NULL then the current time is used.  If tzoff is NULL, then the current
     time zone is used.

     The datestr is a sequence of white-space separated items.  The white-
     space is optional if the concatenated items are not ambiguous.  The
     string contains data which can specify a base time (used in conjunction
     with the time parameter, totally replacing that parameter's value if
     sufficient data appears in datestr to do so), and data specifying an
     offset from the base time.  Both of those are optional.  If no data
     specifies the base time, then parsedate simply uses the value given by
     *time (or now).  If there is no offset data then no offset is applied.
     An empty datestr, or a datestr containing nothing but whitespace, is
     equivalent to midnight at the start of the day specified by *time (or

     The following words have the indicated numeric meanings: last = -1, this
     = 0, first, next, or one = 1, second is unused so that it is not confused
     with "seconds", two = 2, third or three = 3, fourth or four = 4, fifth or
     five = 5, sixth or six = 6, seventh or seven = 7, eighth or eight = 8,
     ninth or nine = 9, tenth or ten = 10, eleventh or eleven = 11, twelfth or
     twelve = 12.

     The following words are recognized in English only: AM, PM, a.m., p.m.,
     midnight, mn, noon.

     The months: january, february, march, april, may, june, july, august,
     september, october, november, december, and common abbreviations for
     them.  When a month name (or its ordinal number) is given, the number of
     some particular day of that month is required to accompany it.  This is
     generally true of any data that specifies a period with a duration longer
     than a day, so simply specifying a year, or a month, is invalid, as also
     is specifying a year and a month.

     The days of the week: sunday, monday, tuesday, wednesday, thursday,
     friday, saturday, and common abbreviations for them.  Weekday names are
     typically ignored if any other data is given to specify the date, even if
     the name given is not the day on which the specified date occurred.

     Time units: year, month, fortnight, week, day, hour, minute, min, second,
     sec, tomorrow, yesterday.

     Timezone names: gmt (+0000), ut (+0000), utc (+0000), wet (+0000), bst
     (+0100), wat (-0100), at (-0200), nft (-0330), nst (-0330), ndt (-0230),
     ast (-0400), adt (-0300), est (-0500), edt (-0400), cst (-0600), cdt
     (-0500), mst (-0700), mdt (-0600), pst (-0800), pdt (-0700), yst (-0900),
     ydt (-0800), hst (-1000), hdt (-0900), cat (-1000), ahst (-1000), nt
     (-1100), idlw (-1200), cet (+0100), met (+0100), mewt (+0100), mest
     (+0200), swt (+0100), sst (+0200), fwt (+0100), fst (+0200), eet (+0200),
     bt (+0300), it (+0330), ist (+0530), ict (+0700), wast (+0800), wadt
     (+0900), awst (+0800), awdt (+0900), cct (+0800), sgt (+0800), hkt
     (+0800), jst (+0900), cast (+0930), cadt (+1030), acst (+0930), acdt
     (+1030), east (+1000), eadt (+1100), aest (+1000), aedt (+1100), gst
     (+1000), nzt (+1200), nzst (+1200), nzdt (+1300), idle (+1200).

     The timezone names simply specify an offset from Coordinated Universal
     Time (UTC) and do not imply validating the time/date to be reasonable in
     any zone that happens to use the abbreviation specified.

     A variety of unambiguous dates are recognized:
     9/10/69      For years between 69-99 we assume 1900+ and for years
                  between 0-68 we assume 2000+.
     2006-11-17   An ISO-8601 date.  Note that when using the ISO-8601 format
                  date and time with the `T' designator to separate date and
                  time-of-day, this must appear at the start of the input
                  string, with no preceding whitespace.  Other modifiers may
                  optionally follow.
     67-09-10     The year in an ISO-8601 date is always taken literally, so
                  this is the year 67, not 2067.
     10/1/2000    October 1, 2000; the common, but bizarre, US format.
     20 Jun 1994
     1-sep-06     Other common abbreviations.
     1/11         The year can be omitted.  A missing year is taken from the
                  *time value, or "now" if time is NULL.  Again, this is the
                  US month/day format (the 11th of January).

     Standard e-mail (RFC822, RFC2822, etc) formats and the output from
     date(1), and asctime(3) are all supported as input, as is cvs date format
     (where years < 100 are treated as 20th century).

     Times can also be specified in common forms:
     Fractions of seconds (after a decimal point, or comma) are parsed, but
     ignored.  If no time is given, midnight on the specified date is assumed.
     If a time is given without a date, that time on the day specified by
     *time (or now) is used.  Missing minutes, or seconds, are taken to be

     A variety of forms for relative items to specify an offset from the base
     time are also supported:
     -1 month
     last friday
     one week ago
     this thursday
     next sunday
     +2 years

     Note that, as a special case for midnight with the name of a day only,
     "midnight tuesday" implies 00:00 at the beginning of Tuesday, (the
     midnight before Tuesday) whereas "Sat mn" implies 00:00 at the end of
     Saturday (midnight after Saturday) (i.e. early Sunday morning).

     Seconds since epoch, UTC, (also known as UNIX time) are also supported to
     specify the base time:
     E.g.: @735275209      to specify: Tue Apr 20 03:06:49 UTC 1993
     provided that the value given is within the range that can be represented
     as a struct tm.  Negative values (times before the epoch) are permitted,
     but no other significant data as part of the base time - the value given
     specifies year, month, day, hour, minute, and second, there is no more.
     An offset from this base time may still be included.  Thus "@735275209 +2
     months 5 hours 15 minutes" produces a time_t which represents "Sun Jun 20
     08:21:49 UTC 1993".

     Text in datestr enclosed in parentheses `(' and `)' is treated as a
     comment, and ignored.  Parentheses nest (the comment ends when there have
     been the same number of closing parentheses as there were opening
     parentheses.)  There is no escape character in comments, `)' always ends
     (or decreases the nesting level of) the comment.

     parsedate() returns the number of seconds passed since, or before (if
     negative,) the Epoch, or -1 if the date could not be parsed properly.  A
     non-error result of -1 can be distinguished from an error by setting
     errno to 0 before calling parsedate(), and checking the value of errno

     If the tzoff parameter is given as NULL, then:

     TZ   The timezone to which the input is relative, when no zone
          information is otherwise specified in the datestr input.

     date(1), touch(1), errno(2), ctime(3), eeprom(8)

     The parser used in parsedate() was originally written by Steven M.
     Bellovin while at the University of North Carolina at Chapel Hill.  It
     was later tweaked by a couple of people on Usenet.  Completely overhauled
     by Rich $alz and Jim Berets in August, 1990.  Further mangled during its
     residence with NetBSD.

     The parsedate() function first appeared in NetBSD 4.0.

     1  The parsedate() function is not re-entrant or thread-safe.
     2  The parsedate() function assumes years less than 0 mean - year, and in
        non ISO formats, that years less than 69 mean 2000 + year, otherwise
        years less than 100 mean 1900 + year.  That is except in the CVS
        format, where years less than 100 mean 1900 + year.
     3  The parsedate() function accepts "12 am" where "12 midnight" is
        correct, and similarly "12 pm" for "12 noon".  The correct forms are
        also accepted.
     4  There are various weird cases that are hard to explain, but are
        nevertheless considered correct.
     5  It is very hard to specify years BC, and in any case, conversions of
        times before the commencement of the modern Gregorian calendar (when
        that occurred depends upon location, but late 16th century is a rough
        guide) are suspicious at best, and depending upon context, often just
        plain wrong.
     6  Despite what is stated above, "next" is actually 2.  The input "next
        January", instead of producing a timestamp for January of the
        following year, produces one for January 2nd, of the current year.
        Use caution with "next" it rarely does what humans expect.  For
        example, on a Sunday "next sunday" means the following Sunday (7 days
        hence) whereas "next monday" means the monday that follows that (8
        days hence) rather than "tomorrow" or just "Mon" (without the "next")
        which is the nearest subsequent Monday.

NetBSD 10.99                     May 16, 2021                     NetBSD 10.99