2011-02-12 00:22:29 -05:00
|
|
|
#include <stdlib.h>
|
|
|
|
#include <langinfo.h>
|
|
|
|
#include <time.h>
|
2011-08-16 10:38:33 -04:00
|
|
|
#include <ctype.h>
|
|
|
|
#include <stddef.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <strings.h>
|
2011-02-12 00:22:29 -05:00
|
|
|
|
2012-09-06 22:44:55 -04:00
|
|
|
char *strptime(const char *restrict s, const char *restrict f, struct tm *restrict tm)
|
2011-02-12 00:22:29 -05:00
|
|
|
{
|
fix unhandled cases in strptime
%C, %U, %W, and %y handling were completely missing; %C wrongly
fell-through to unrelated cases, and the rest returned failure. for
now, they all parse numbers in the proper forms and range-check the
values, but they do not store the value anywhere.
it's not clear to me whether, as "derived" fields, %U and %W should
produce any result. they certainly cannot produce a result unless the
year and weekday are also converted, but in this case it might be
desirable for them to do so. clarification is needed on the intended
behavior of strptime in cases like this.
%C and %y have well-defined behavior as long as they are used together
(and %y is defined by itself but may change in the future).
implementing them (including their correct interaction) is left as a
later change to be made.
finally, strptime now rejects unknown/invalid format characters
instead of ignoring them.
2014-05-19 22:14:09 -04:00
|
|
|
int i, w, neg, adj, min, range, *dest, dummy;
|
2011-08-16 10:38:33 -04:00
|
|
|
const char *ex;
|
|
|
|
size_t len;
|
2014-05-14 10:53:56 +03:00
|
|
|
int want_century = 0, century = 0;
|
2011-08-16 10:38:33 -04:00
|
|
|
while (*f) {
|
|
|
|
if (*f != '%') {
|
|
|
|
if (isspace(*f)) for (; *s && isspace(*s); s++);
|
|
|
|
else if (*s != *f) return 0;
|
|
|
|
else s++;
|
|
|
|
f++;
|
2012-03-02 00:23:43 -05:00
|
|
|
continue;
|
2011-08-16 10:38:33 -04:00
|
|
|
}
|
|
|
|
f++;
|
|
|
|
if (*f == '+') f++;
|
|
|
|
if (isdigit(*f)) w=strtoul(f, (void *)&f, 10);
|
|
|
|
else w=-1;
|
|
|
|
adj=0;
|
|
|
|
switch (*f++) {
|
|
|
|
case 'a': case 'A':
|
|
|
|
dest = &tm->tm_wday;
|
|
|
|
min = ABDAY_1;
|
|
|
|
range = 7;
|
|
|
|
goto symbolic_range;
|
|
|
|
case 'b': case 'B': case 'h':
|
|
|
|
dest = &tm->tm_mon;
|
|
|
|
min = ABMON_1;
|
|
|
|
range = 12;
|
|
|
|
goto symbolic_range;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'c':
|
2011-08-16 10:38:33 -04:00
|
|
|
s = strptime(s, nl_langinfo(D_T_FMT), tm);
|
|
|
|
if (!s) return 0;
|
|
|
|
break;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'C':
|
2014-05-14 10:53:56 +03:00
|
|
|
dest = ¢ury;
|
fix unhandled cases in strptime
%C, %U, %W, and %y handling were completely missing; %C wrongly
fell-through to unrelated cases, and the rest returned failure. for
now, they all parse numbers in the proper forms and range-check the
values, but they do not store the value anywhere.
it's not clear to me whether, as "derived" fields, %U and %W should
produce any result. they certainly cannot produce a result unless the
year and weekday are also converted, but in this case it might be
desirable for them to do so. clarification is needed on the intended
behavior of strptime in cases like this.
%C and %y have well-defined behavior as long as they are used together
(and %y is defined by itself but may change in the future).
implementing them (including their correct interaction) is left as a
later change to be made.
finally, strptime now rejects unknown/invalid format characters
instead of ignoring them.
2014-05-19 22:14:09 -04:00
|
|
|
if (w<0) w=2;
|
2014-05-14 10:53:56 +03:00
|
|
|
want_century |= 2;
|
fix unhandled cases in strptime
%C, %U, %W, and %y handling were completely missing; %C wrongly
fell-through to unrelated cases, and the rest returned failure. for
now, they all parse numbers in the proper forms and range-check the
values, but they do not store the value anywhere.
it's not clear to me whether, as "derived" fields, %U and %W should
produce any result. they certainly cannot produce a result unless the
year and weekday are also converted, but in this case it might be
desirable for them to do so. clarification is needed on the intended
behavior of strptime in cases like this.
%C and %y have well-defined behavior as long as they are used together
(and %y is defined by itself but may change in the future).
implementing them (including their correct interaction) is left as a
later change to be made.
finally, strptime now rejects unknown/invalid format characters
instead of ignoring them.
2014-05-19 22:14:09 -04:00
|
|
|
goto numeric_digits;
|
2011-08-16 10:38:33 -04:00
|
|
|
case 'd': case 'e':
|
|
|
|
dest = &tm->tm_mday;
|
|
|
|
min = 1;
|
|
|
|
range = 31;
|
|
|
|
goto numeric_range;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'D':
|
2011-08-16 10:38:33 -04:00
|
|
|
s = strptime(s, "%m/%d/%y", tm);
|
|
|
|
if (!s) return 0;
|
|
|
|
break;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'H':
|
2011-08-16 10:38:33 -04:00
|
|
|
dest = &tm->tm_hour;
|
|
|
|
min = 0;
|
|
|
|
range = 24;
|
|
|
|
goto numeric_range;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'I':
|
2011-08-16 10:38:33 -04:00
|
|
|
dest = &tm->tm_hour;
|
|
|
|
min = 1;
|
|
|
|
range = 12;
|
|
|
|
goto numeric_range;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'j':
|
2011-08-16 10:38:33 -04:00
|
|
|
dest = &tm->tm_yday;
|
|
|
|
min = 1;
|
|
|
|
range = 366;
|
|
|
|
goto numeric_range;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'm':
|
2011-08-16 10:38:33 -04:00
|
|
|
dest = &tm->tm_mon;
|
|
|
|
min = 1;
|
|
|
|
range = 12;
|
|
|
|
adj = 1;
|
|
|
|
goto numeric_range;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'M':
|
2011-08-16 10:38:33 -04:00
|
|
|
dest = &tm->tm_min;
|
|
|
|
min = 0;
|
|
|
|
range = 60;
|
|
|
|
goto numeric_range;
|
|
|
|
case 'n': case 't':
|
|
|
|
for (; *s && isspace(*s); s++);
|
|
|
|
break;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'p':
|
2011-08-16 10:38:33 -04:00
|
|
|
ex = nl_langinfo(AM_STR);
|
|
|
|
len = strlen(ex);
|
|
|
|
if (!strncasecmp(s, ex, len)) {
|
|
|
|
tm->tm_hour %= 12;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
ex = nl_langinfo(PM_STR);
|
|
|
|
len = strlen(ex);
|
|
|
|
if (!strncasecmp(s, ex, len)) {
|
|
|
|
tm->tm_hour %= 12;
|
|
|
|
tm->tm_hour += 12;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return 0;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'r':
|
2011-08-16 10:38:33 -04:00
|
|
|
s = strptime(s, nl_langinfo(T_FMT_AMPM), tm);
|
|
|
|
if (!s) return 0;
|
|
|
|
break;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'R':
|
2011-08-16 10:38:33 -04:00
|
|
|
s = strptime(s, "%H:%M", tm);
|
|
|
|
if (!s) return 0;
|
|
|
|
break;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'S':
|
2011-08-16 10:38:33 -04:00
|
|
|
dest = &tm->tm_sec;
|
|
|
|
min = 0;
|
|
|
|
range = 61;
|
|
|
|
goto numeric_range;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'T':
|
2011-08-16 10:38:33 -04:00
|
|
|
s = strptime(s, "%H:%M:%S", tm);
|
|
|
|
if (!s) return 0;
|
|
|
|
break;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'U':
|
|
|
|
case 'W':
|
fix unhandled cases in strptime
%C, %U, %W, and %y handling were completely missing; %C wrongly
fell-through to unrelated cases, and the rest returned failure. for
now, they all parse numbers in the proper forms and range-check the
values, but they do not store the value anywhere.
it's not clear to me whether, as "derived" fields, %U and %W should
produce any result. they certainly cannot produce a result unless the
year and weekday are also converted, but in this case it might be
desirable for them to do so. clarification is needed on the intended
behavior of strptime in cases like this.
%C and %y have well-defined behavior as long as they are used together
(and %y is defined by itself but may change in the future).
implementing them (including their correct interaction) is left as a
later change to be made.
finally, strptime now rejects unknown/invalid format characters
instead of ignoring them.
2014-05-19 22:14:09 -04:00
|
|
|
/* Throw away result, for now. (FIXME?) */
|
|
|
|
dest = &dummy;
|
|
|
|
min = 0;
|
|
|
|
range = 54;
|
|
|
|
goto numeric_range;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'w':
|
2011-08-16 10:38:33 -04:00
|
|
|
dest = &tm->tm_wday;
|
|
|
|
min = 0;
|
|
|
|
range = 7;
|
|
|
|
goto numeric_range;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'x':
|
2011-08-16 10:38:33 -04:00
|
|
|
s = strptime(s, nl_langinfo(D_FMT), tm);
|
|
|
|
if (!s) return 0;
|
|
|
|
break;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'X':
|
2011-08-16 10:38:33 -04:00
|
|
|
s = strptime(s, nl_langinfo(T_FMT), tm);
|
|
|
|
if (!s) return 0;
|
|
|
|
break;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'y':
|
2014-05-14 10:53:56 +03:00
|
|
|
dest = &tm->tm_year;
|
fix unhandled cases in strptime
%C, %U, %W, and %y handling were completely missing; %C wrongly
fell-through to unrelated cases, and the rest returned failure. for
now, they all parse numbers in the proper forms and range-check the
values, but they do not store the value anywhere.
it's not clear to me whether, as "derived" fields, %U and %W should
produce any result. they certainly cannot produce a result unless the
year and weekday are also converted, but in this case it might be
desirable for them to do so. clarification is needed on the intended
behavior of strptime in cases like this.
%C and %y have well-defined behavior as long as they are used together
(and %y is defined by itself but may change in the future).
implementing them (including their correct interaction) is left as a
later change to be made.
finally, strptime now rejects unknown/invalid format characters
instead of ignoring them.
2014-05-19 22:14:09 -04:00
|
|
|
w = 2;
|
2014-05-14 10:53:56 +03:00
|
|
|
want_century |= 1;
|
fix unhandled cases in strptime
%C, %U, %W, and %y handling were completely missing; %C wrongly
fell-through to unrelated cases, and the rest returned failure. for
now, they all parse numbers in the proper forms and range-check the
values, but they do not store the value anywhere.
it's not clear to me whether, as "derived" fields, %U and %W should
produce any result. they certainly cannot produce a result unless the
year and weekday are also converted, but in this case it might be
desirable for them to do so. clarification is needed on the intended
behavior of strptime in cases like this.
%C and %y have well-defined behavior as long as they are used together
(and %y is defined by itself but may change in the future).
implementing them (including their correct interaction) is left as a
later change to be made.
finally, strptime now rejects unknown/invalid format characters
instead of ignoring them.
2014-05-19 22:14:09 -04:00
|
|
|
goto numeric_digits;
|
2011-02-12 00:22:29 -05:00
|
|
|
case 'Y':
|
2011-08-16 10:38:33 -04:00
|
|
|
dest = &tm->tm_year;
|
|
|
|
if (w<0) w=4;
|
|
|
|
adj = 1900;
|
2014-05-14 10:53:56 +03:00
|
|
|
want_century = 0;
|
2011-08-16 10:38:33 -04:00
|
|
|
goto numeric_digits;
|
|
|
|
case '%':
|
|
|
|
if (*s++ != '%') return 0;
|
|
|
|
break;
|
fix unhandled cases in strptime
%C, %U, %W, and %y handling were completely missing; %C wrongly
fell-through to unrelated cases, and the rest returned failure. for
now, they all parse numbers in the proper forms and range-check the
values, but they do not store the value anywhere.
it's not clear to me whether, as "derived" fields, %U and %W should
produce any result. they certainly cannot produce a result unless the
year and weekday are also converted, but in this case it might be
desirable for them to do so. clarification is needed on the intended
behavior of strptime in cases like this.
%C and %y have well-defined behavior as long as they are used together
(and %y is defined by itself but may change in the future).
implementing them (including their correct interaction) is left as a
later change to be made.
finally, strptime now rejects unknown/invalid format characters
instead of ignoring them.
2014-05-19 22:14:09 -04:00
|
|
|
default:
|
|
|
|
return 0;
|
2011-08-16 10:38:33 -04:00
|
|
|
numeric_range:
|
|
|
|
if (!isdigit(*s)) return 0;
|
|
|
|
*dest = 0;
|
|
|
|
for (i=1; i<=min+range && isdigit(*s); i*=10)
|
|
|
|
*dest = *dest * 10 + *s++ - '0';
|
|
|
|
if (*dest - min >= (unsigned)range) return 0;
|
|
|
|
*dest -= adj;
|
|
|
|
switch((char *)dest - (char *)tm) {
|
|
|
|
case offsetof(struct tm, tm_yday):
|
|
|
|
;
|
|
|
|
}
|
|
|
|
goto update;
|
|
|
|
numeric_digits:
|
|
|
|
neg = 0;
|
|
|
|
if (*s == '+') s++;
|
|
|
|
else if (*s == '-') neg=1, s++;
|
|
|
|
if (!isdigit(*s)) return 0;
|
2011-09-05 15:39:36 -04:00
|
|
|
for (*dest=i=0; i<w && isdigit(*s); i++)
|
2011-08-16 10:38:33 -04:00
|
|
|
*dest = *dest * 10 + *s++ - '0';
|
|
|
|
if (neg) *dest = -*dest;
|
|
|
|
*dest -= adj;
|
|
|
|
goto update;
|
|
|
|
symbolic_range:
|
|
|
|
for (i=2*range-1; i>=0; i--) {
|
|
|
|
ex = nl_langinfo(min+i);
|
|
|
|
len = strlen(ex);
|
|
|
|
if (strncasecmp(s, ex, len)) continue;
|
2012-03-02 00:23:43 -05:00
|
|
|
s += len;
|
2011-08-16 10:38:33 -04:00
|
|
|
*dest = i % range;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (i<0) return 0;
|
|
|
|
goto update;
|
|
|
|
update:
|
|
|
|
//FIXME
|
|
|
|
;
|
2011-02-12 00:22:29 -05:00
|
|
|
}
|
|
|
|
}
|
2014-05-14 10:53:56 +03:00
|
|
|
if (want_century) {
|
|
|
|
if (want_century & 2) tm->tm_year += century * 100 - 1900;
|
|
|
|
else if (tm->tm_year <= 68) tm->tm_year += 100;
|
|
|
|
}
|
2011-08-16 10:38:33 -04:00
|
|
|
return (char *)s;
|
2011-02-12 00:22:29 -05:00
|
|
|
}
|