about summary refs log tree commit diff
path: root/manual/time.texi
diff options
context:
space:
mode:
authorUlrich Drepper <drepper@redhat.com>1998-12-15 16:47:38 +0000
committerUlrich Drepper <drepper@redhat.com>1998-12-15 16:47:38 +0000
commite9dcb080809726a5531d2b5932b7f47e61d4bc49 (patch)
tree623dd875878dbf351ee16604ac5acddbcb9eb6cf /manual/time.texi
parent5a7cb1a2c7ba6bc3524a26f63c50ca7cf0740769 (diff)
downloadglibc-e9dcb080809726a5531d2b5932b7f47e61d4bc49.tar.gz
glibc-e9dcb080809726a5531d2b5932b7f47e61d4bc49.tar.xz
glibc-e9dcb080809726a5531d2b5932b7f47e61d4bc49.zip
Update.
	* sysdeps/unix/sysv/linux/msgctl.c: Use INLINE_SYSCALL.
	* sysdeps/unix/sysv/linux/msgget.c: Likewise.
	* sysdeps/unix/sysv/linux/msgrcv.c: Likewise.
	* sysdeps/unix/sysv/linux/msgsnd.c: Likewise.
	* sysdeps/unix/sysv/linux/semctl.c: Likewise.
	* sysdeps/unix/sysv/linux/semget.c: Likewise.
	* sysdeps/unix/sysv/linux/semop.c: Likewise.
	* sysdeps/unix/sysv/linux/shmat.c: Likewise.
	* sysdeps/unix/sysv/linux/shmctl.c: Likewise.
	* sysdeps/unix/sysv/linux/shmdt.c: Likewise.
	* sysdeps/unix/sysv/linux/shmget.c: Likewise.
	* sysdeps/unix/sysv/linux/syscalls.list: Remove ipc syscall here.
	* sysdeps/unix/sysv/linux/powerpc/syscalls.list: Add ipc syscall here.

	* time/strftime.c: Remove 'f' format.

	* time/strptime.c (get_number): Ignore trailing whitespace.
	(strptime_internal): Handle 'F' and 'k' formats.
Diffstat (limited to 'manual/time.texi')
-rw-r--r--manual/time.texi553
1 files changed, 542 insertions, 11 deletions
diff --git a/manual/time.texi b/manual/time.texi
index 46a2832326..7b58ad4400 100644
--- a/manual/time.texi
+++ b/manual/time.texi
@@ -82,7 +82,7 @@ elapsed = ((double) (end - start)) / CLOCKS_PER_SEC;
 
 Different computers and operating systems vary wildly in how they keep
 track of processor time.  It's common for the internal processor clock
-to have a resolution somewhere between hundredths and millionths of a
+to have a resolution somewhere between hundredth and millionth of a
 second.
 
 In the GNU system, @code{clock_t} is equivalent to @code{long int} and
@@ -224,6 +224,8 @@ date and time values.
 * High-Resolution Calendar::    A time representation with greater precision.
 * Broken-down Time::            Facilities for manipulating local time.
 * Formatting Date and Time::    Converting times to strings.
+* Parsing Date and Time::       Convert textual time and date information back
+                                 into broken-down time values.
 * TZ Variable::                 How users specify the time zone.
 * Time Zone Functions::         Functions to examine or specify the time zone.
 * Time Functions Example::      An example program showing use of some of
@@ -689,7 +691,6 @@ return @code{NULL}.
 
 @comment time.h
 @comment ISO
-@comment POSIX.2
 @deftypefun size_t strftime (char *@var{s}, size_t @var{size}, const char *@var{template}, const struct tm *@var{brokentime})
 This function is similar to the @code{sprintf} function (@pxref{Formatted
 Input}), but the conversion specifications that can appear in the format
@@ -789,12 +790,6 @@ The day of the month like with @code{%d}, but padded with blank (range
 
 This format is a POSIX.2 extension.
 
-@item %f
-The day of the week as a decimal number (range @code{1} through
-@code{7}), Monday being @code{1}.
-
-This format is a @w{ISO C 9X} extension.
-
 @item %F
 The date using the format @code{%Y-%m-%d}.  This is the form specified
 in the @w{ISO 8601} standard and is the preferred form for all uses.
@@ -890,7 +885,7 @@ Leap seconds are not counted unless leap second support is available.
 This format is a GNU extension.
 
 @item %S
-The second as a decimal number (range @code{00} through @code{60}).
+The seconds as a decimal number (range @code{00} through @code{60}).
 
 @item %t
 A single @samp{\t} (tabulator) character.
@@ -959,8 +954,8 @@ determinable.
 
 This format is a GNU extension.
 
-A full @w{RFC 822} timestamp is generated by the format 
-@w{@samp{"%a, %d %b %Y %H:%M:%S %z"}} (or the equivalent 
+A full @w{RFC 822} timestamp is generated by the format
+@w{@samp{"%a, %d %b %Y %H:%M:%S %z"}} (or the equivalent
 @w{@samp{"%a, %d %b %Y %T %z"}}).
 
 @item %Z
@@ -1008,6 +1003,542 @@ is examined before any output is produced.
 For an example of @code{strftime}, see @ref{Time Functions Example}.
 @end deftypefun
 
+@node Parsing Date and Time
+@subsection Convert textual time and date information back
+
+The @w{ISO C} standard does not specify any functions which can convert
+the output of the @code{strftime} function back into a binary format.
+This lead to variety of more or less successful implementations with
+different interfaces over the years.  Then the Unix standard got
+extended by two functions: @code{strptime} and @code{getdate}.  Both
+have kind of strange interfaces but at least they are widely available.
+
+@menu
+* Low-Level Time String Parsing::  Interpret string according to given format.
+* General Time String Parsing::    User-friendly function to parse data and
+                                    time strings.
+@end menu
+
+@node Low-Level Time String Parsing
+@subsubsection Interpret string according to given format
+
+The first function is a rather low-level interface.  It is nevertheless
+frequently used in user programs since it is better known.  Its
+implementation and the interface though is heavily influenced by the
+@code{getdate} function which is defined and implemented in terms of
+calls to @code{strptime}.
+
+@comment time.h
+@comment XPG4
+@deftypefun {char *} strptime (const char *@var{s}, const char *@var{fmt}, struct tm *@var{tp})
+The @code{strptime} function parses the input string @var{s} according
+to the format string @var{fmt} and stores the found values in the
+structure @var{tp}.
+
+The input string can be retrieved in any way.  It does not matter
+whether it was generated by a @code{strftime} call or made up directly
+by a program.  It is also not necessary that the content is in any
+human-recognizable format.  I.e., it is OK if a date is written like
+@code{"02:1999:9"} which is not understandable without context.  As long
+the format string @var{fmt} matches the format of the input string
+everything goes.
+
+The format string consists of the same components as the format string
+for the @code{strftime} function.  The only difference is that the flags
+@code{_}, @code{-}, @code{0}, and @code{^} are not allowed.
+@comment Is this really the intention?  --drepper
+Several of the formats which @code{strftime} handled differently do the
+same work in @code{strptime} since differences like case of the output
+do not matter.  For symmetry reasons all formats are supported, though.
+
+The modifiers @code{E} and @code{O} are also allowed everywhere the
+@code{strftime} function allows them.
+
+The formats are:
+
+@table @code
+@item %a
+@itemx %A
+The weekday name according to the current locale, in abbreviated form or
+the full name.
+
+@item %b
+@itemx %B
+@itemx %h
+The month name according to the current locale, in abbreviated form or
+the full name.
+
+@item %c
+The date and time representation for the current locale.
+
+@item %Ec
+Like @code{%c} but the locale's alternative date and time format is used.
+
+@item %C
+The century of the year.
+
+It makes sense to use this format only if the format string also
+contains the @code{%y} format.
+
+@item %EC
+The locale's representation of the period.
+
+Unlike @code{%C} it makes sometimes sense to use this format since in
+some cultures it is required to specify years relative to periods
+instead of using the Gregorian years.
+
+@item %d
+@item %e
+The day of the month as a decimal number (range @code{1} through @code{31}).
+Leading zeroes are permitted but not required.
+
+@item %Od
+@itemx %Oe
+Same as @code{%d} but the locale's alternative numeric symbols are used.
+
+Leading zeroes are permitted but not required.
+
+@item %D
+Equivalent to the use of @code{%m/%d/%y} in this place.
+
+@item %F
+Equivalent to the use of @code{%Y-%m-%d} which is the @w{ISO 8601} date
+format.
+
+This is a GNU extension following an @w{ISO C 9X} extension to
+@code{strftime}.
+
+@item %g
+The year corresponding to the ISO week number, but without the century
+(range @code{00} through @code{99}).
+
+@emph{Note:} This is not really implemented currently.  The format is
+recognized, input is consumed but no field in @var{tm} is set.
+
+This format is a GNU extension following a GNU extension of @code{strftime}.
+
+@item %G
+The year corresponding to the ISO week number.
+
+@emph{Note:} This is not really implemented currently.  The format is
+recognized, input is consumed but no field in @var{tm} is set.
+
+This format is a GNU extension following a GNU extension of @code{strftime}.
+
+@item %H
+@itemx %k
+The hour as a decimal number, using a 24-hour clock (range @code{00} through
+@code{23}).
+
+@code{%k} is a GNU extension following a GNU extension of @code{strftime}.
+
+@item %OH
+Same as @code{%H} but using the locale's alternative numeric symbols are used.
+
+@item %I
+@itemx %l
+The hour as a decimal number, using a 12-hour clock (range @code{01} through
+@code{12}).
+
+@code{%l} is a GNU extension following a GNU extension of @code{strftime}.
+
+@item %OI
+Same as @code{%I} but using the locale's alternative numeric symbols are used.
+
+@item %j
+The day of the year as a decimal number (range @code{1} through @code{366}).
+
+Leading zeroes are permitted but not required.
+
+@item %m
+The month as a decimal number (range @code{1} through @code{12}).
+
+Leading zeroes are permitted but not required.
+
+@item %Om
+Same as @code{%m} but using the locale's alternative numeric symbols are used.
+
+@item %M
+The minute as a decimal number (range @code{0} through @code{59}).
+
+Leading zeroes are permitted but not required.
+
+@item %OM
+Same as @code{%M} but using the locale's alternative numeric symbols are used.
+
+@item %n
+@itemx %t
+Matches any white space.
+
+@item %p
+@item %P
+The locale-dependent equivalent to @samp{AM} or @samp{PM}.
+
+This format is not useful unless @code{%I} or @code{%l} is also used.
+Another complication is that the locale might not define these values at
+all and therefore the conversion fails.
+
+@code{%P} is a GNU extension following a GNU extension to @code{strftime}.
+
+@item %r
+The complete time using the AM/PM format of the current locale.
+
+A complication is that the locale might not define this format at all
+and therefore the conversion fails.
+
+@item %R
+The hour and minute in decimal numbers using the format @code{%H:%M}.
+
+@code{%R} is a GNU extension following a GNU extension to @code{strftime}.
+
+@item %s
+The number of seconds since the epoch, i.e., since 1970-01-01 00:00:00 UTC.
+Leap seconds are not counted unless leap second support is available.
+
+@code{%s} is a GNU extension following a GNU extension to @code{strftime}.
+
+@item %S
+The seconds as a decimal number (range @code{0} through @code{61}).
+
+Leading zeroes are permitted but not required.
+
+Please note the nonsense with @code{61} being allowed.  This is what the
+Unix specification says.  They followed the stupid decision once made to
+allow double leap seconds.  These do not exist but the myth persists.
+
+@item %OS
+Same as @code{%S} but using the locale's alternative numeric symbols are used.
+
+@item %T
+Equivalent to the use of @code{%H:%M:%S} in this place.
+
+@item %u
+The day of the week as a decimal number (range @code{1} through
+@code{7}), Monday being @code{1}.
+
+Leading zeroes are permitted but not required.
+
+@emph{Note:} This is not really implemented currently.  The format is
+recognized, input is consumed but no field in @var{tm} is set.
+
+@item %U
+The week number of the current year as a decimal number (range @code{0}
+through @code{53}).
+
+Leading zeroes are permitted but not required.
+
+@item %OU
+Same as @code{%U} but using the locale's alternative numeric symbols are used.
+
+@item %V
+The @w{ISO 8601:1988} week number as a decimal number (range @code{1}
+through @code{53}).
+
+Leading zeroes are permitted but not required.
+
+@emph{Note:} This is not really implemented currently.  The format is
+recognized, input is consumed but no field in @var{tm} is set.
+
+@item %w
+The day of the week as a decimal number (range @code{0} through
+@code{6}), Sunday being @code{0}.
+
+Leading zeroes are permitted but not required.
+
+@emph{Note:} This is not really implemented currently.  The format is
+recognized, input is consumed but no field in @var{tm} is set.
+
+@item %Ow
+Same as @code{%w} but using the locale's alternative numeric symbols are used.
+
+@item %W
+The week number of the current year as a decimal number (range @code{0}
+through @code{53}).
+
+Leading zeroes are permitted but not required.
+
+@emph{Note:} This is not really implemented currently.  The format is
+recognized, input is consumed but no field in @var{tm} is set.
+
+@item %OW
+Same as @code{%W} but using the locale's alternative numeric symbols are used.
+
+@item %x
+The date using the locale's date format.
+
+@item %Ex
+Like @code{%x} but the locale's alternative data representation is used.
+
+@item %X
+The time using the locale's time format.
+
+@item %EX
+Like @code{%X} but the locale's alternative time representation is used.
+
+@item %y
+The year without a century as a decimal number (range @code{0} through
+@code{99}).
+
+Leading zeroes are permitted but not required.
+
+Please note that it is at least questionable to use this format without
+the @code{%C} format.  The @code{strptime} function does regard input
+values in the range @math{68} to @math{99} as the years @math{1969} to
+@math{1999} and the values @math{0} to @math{68} as the years
+@math{2000} to @math{2068}.  But maybe this heuristic fails for some
+input data.
+
+Therefore it is best to avoid @code{%y} completely and use @code{%Y}
+instead.
+
+@item %Ey
+The offset from @code{%EC} in the locale's alternative representation.
+
+@item %Oy
+The offset of the year (from @code{%C}) using the locale's alternative
+numeric symbols.
+
+@item %Y
+The year as a decimal number, using the Gregorian calendar.
+
+@item %EY
+The full alternative year representation.
+
+@item %z
+Equivalent to the use of @code{%a, %d %b %Y %H:%M:%S %z} in this place.
+This is the full @w{ISO 8601} date and time format.
+
+@item %Z
+The timezone name.
+
+@emph{Note:} This is not really implemented currently.  The format is
+recognized, input is consumed but no field in @var{tm} is set.
+
+@item %%
+A literal @samp{%} character.
+@end table
+
+All other characters in the format string must have a matching character
+in the input string.  Exceptions are white spaces in the input string
+which can match zero or more white space characters in the input string.
+
+The @code{strptime} function processes the input string from right to
+left.  Each of the three possible input elements (white space, literal,
+or format) are handled one after the other.  If the input cannot be
+matched to the format string the function stops.  The remainder of the
+format and input strings are not processed.
+
+The return value of the function is a pointer to the first character not
+processed in this function call.  In the case of an error the return
+value points to the first character not matched.  In case the input
+string contains more than required by the format string the return value
+points right after the last consumed input character.  In case the whole
+input string is consumed the return value points to the NUL byte at the
+end of the string.
+@end deftypefun
+
+The specification of the function in the XPG standard is rather vague.
+It leaves out a few important pieces of information.  Most important it
+does not specify what happens to those elements of @var{tm} which are
+not directly initialized by the different formats.  Various
+implementations on different Unix systems vary here.
+
+The GNU libc implementation does not touch those fields which are not
+directly initialized.  Exceptions are the @code{tm_wday} and
+@code{tm_yday} elements which are recomputed if any of the year, month,
+or date elements changed.  This has two implications:
+
+@itemize @bullet
+@item
+Before calling the @code{strptime} function for a new input string one
+has to prepare the structure passed in as the @var{tm}.  Normally this
+will mean that all values are initialized to zero.  Alternatively one
+can use all fields to values like @code{INT_MAX} which allows to
+determine which elements were set by the function call.  Zero does not
+work here since it is a valid value for many of the fields.
+
+Careful initialization is necessary if one wants to find out whether a
+certain field in @var{tm} was initialized by the function call.
+
+@item
+One can construct a @code{struct tm} value in several @code{strptime}
+calls in a row.  A useful application of this is for example the parsing
+of two separate strings, one containing the date information, the other
+the time information.  By parsing both one after the other without
+clearing the structure in between one can construct a complete
+broken-down time.
+@end itemize
+
+The following example shows a function which parses a string which is
+supposed to contain the date information in either US style or @w{ISO
+8601} form.
+
+@smallexample
+const char *
+parse_date (const char *input, struct tm *tm)
+@{
+  const char *cp;
+
+  /* @r{First clear the result structure.}  */
+  memset (tm, '\0', sizeof (*tm));
+
+  /* @r{Try the ISO format first.}  */
+  cp = strptime (input, "%F", tm);
+  if (cp == NULL)
+    @{
+      /* @r{Does not match.  Try the US form.}  */
+      cp = strptime (input, "%D", tm);
+    @}
+
+  return cp;
+@}
+@end smallexample
+
+@node General Time String Parsing
+@subsubsection A user-friendlier way to parse times and dates
+
+The Unix standard defines another function to parse date strings.  The
+interface is, mildly said, weird.  But if this function fits into the
+application to be written it is just fine.  It is a problem when using
+this function in multi-threaded programs or in libraries since it
+returns a pointer to a static variable, uses a global variable, and a
+global state (an environment variable).
+
+@comment time.h
+@comment Unix98
+@defvar getdate_err
+This variable of type @code{int} will contain the error code of the last
+unsuccessful call of the @code{getdate} function.  Defined values are:
+
+@table @math
+@item 1
+The environment variable @code{DATEMSK} is not defined or null.
+@item 2
+The template file denoted by the @code{DATEMSK} environment variable
+cannot be opened.
+@item 3
+Information about the template file cannot retrieved.
+@item 4
+The template file is no regular file.
+@item 5
+An I/O error occurred while reading the template file.
+@item 6
+Not enough memory available to execute the function.
+@item 7
+The template file contains no matching template.
+@item 8
+The input string is invalid for a template which would match otherwise.
+This includes error like February 31st, or return values which can be
+represented using @code{time_t}.
+@end table
+@end defvar
+
+@comment time.h
+@comment Unix98
+@deftypefun {struct tm *} getdate (const char *@var{string})
+The interface of the @code{getdate} function is the simplest possible
+for a function to parse a string and return the value.  @var{string} is
+the input string and the result is passed to the user in a statically
+allocated variable.
+
+The details about how the string is processed is hidden from the user.
+In fact, it can be outside the control of the program.  Which formats
+are recognized is controlled by the file named by the environment
+variable @code{DATEMSK}.  The content of the named file should contain
+lines of valid format strings which could be passed to @code{strptime}.
+
+The @code{getdate} function reads these format strings one after the
+other and tries to match the input string.  The first line which
+completely matches the input string is used.
+
+Elements which were not initialized through the format string get
+assigned the values of the time the @code{getdate} function is called.
+
+The format elements recognized by @code{getdate} are the same as for
+@code{strptime}.  See above for an explanation.  There are only a few
+extension to the @code{strptime} behavior:
+
+@itemize @bullet
+@item
+If the @code{%Z} format is given the broken-down time is based on the
+current time in the timezone matched, not in the current timezone of the
+runtime environment.
+
+@emph{Note}: This is not implemented (currently).  The problem is that
+timezone names are not unique.  If a fixed timezone is assumed for a
+given string (say @code{EST} meaning US East Coast time) uses for
+countries other than the USA will fail.  So far we have found no good
+solution for this.
+
+@item
+If only the weekday is specified the selected day depends on the current
+date.  If the current weekday is greater or equal to the @code{tm_wday}
+value this weeks day is selected.  Otherwise next weeks day.
+
+@item
+A similar heuristic is used if only the month is given, not the year.
+For value corresponding to the current or a later month the current year
+s used.  Otherwise the next year.  The first day of the month is assumed
+if it is not explicitly specified.
+
+@item
+The current hour, minute, and second is used if the appropriate value is
+not set through the format.
+
+@item
+If no date is given the date for the next day is used if the time is
+smaller than the current time.  Otherwise it is the same day.
+@end itemize
+
+It should be noted that the format in the template file need not only
+contain format elements.  The following is a list of possible format
+strings (taken from the Unix standard):
+
+@smallexample
+%m
+%A %B %d, %Y %H:%M:%S
+%A
+%B
+%m/%d/%y %I %p
+%d,%m,%Y %H:%M
+at %A the %dst of %B in %Y
+run job at %I %p,%B %dnd
+%A den %d. %B %Y %H.%M Uhr
+@end smallexample
+
+As one can see the template list can contain very specific strings like
+@code{run job at %I %p,%B %dnd}.  Using the above list of templates and
+assuming the current time is Mon Sep 22 12:19:47 EDT 1986 we can get the
+The results for the given input.
+
+@multitable {xxxxxxxxxxxx} {xxxxxxxx} {xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}
+@item        Mon @tab       %a @tab    Mon Sep 22 12:19:47 EDT 1986
+@item        Sun @tab       %a @tab    Sun Sep 28 12:19:47 EDT 1986
+@item        Fri @tab       %a @tab    Fri Sep 26 12:19:47 EDT 1986
+@item        September @tab %B @tab    Mon Sep 1 12:19:47 EDT 1986
+@item        January @tab   %B @tab    Thu Jan 1 12:19:47 EST 1987
+@item        December @tab  %B @tab    Mon Dec 1 12:19:47 EST 1986
+@item        Sep Mon @tab   %b %a @tab Mon Sep 1 12:19:47 EDT 1986
+@item        Jan Fri @tab   %b %a @tab Fri Jan 2 12:19:47 EST 1987
+@item        Dec Mon @tab   %b %a @tab Mon Dec 1 12:19:47 EST 1986
+@item        Jan Wed 1989 @tab  %b %a %Y @tab Wed Jan 4 12:19:47 EST 1989
+@item        Fri 9 @tab     %a %H @tab Fri Sep 26 09:00:00 EDT 1986
+@item        Feb 10:30 @tab %b %H:%S @tab Sun Feb 1 10:00:30 EST 1987
+@item        10:30 @tab     %H:%M @tab Tue Sep 23 10:30:00 EDT 1986
+@item        13:30 @tab     %H:%M @tab Mon Sep 22 13:30:00 EDT 1986
+@end multitable
+
+The return value of the function is a pointer to a static variable of
+type @w{@code{struct tm}} or a null pointer if an error occurred.  The
+result in the variable pointed to by the return value is only valid
+until the next @code{getdate} call which makes this function unusable in
+multi-threaded applications.
+
+The @code{errno} variable is @emph{not} changed.  Error conditions are
+signalled using the global variable @code{getdate_err}.  See the
+description above for a list of the possible error values.
+@end deftypefun
+
 @node TZ Variable
 @subsection Specifying the Time Zone with @code{TZ}