There’s something not quite right with the “date” command in the MotionEye OS which makes use of busybox. I try to set the day to the current date but the resultant year keeps increasing by 1 each time I do a “date –s” [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20190818 [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20200818 [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20210818 [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20220818 [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20230818 ______________________________________________________________________________ Hi Kenneth, I tried this myself and saw that strange behavior. I don't know what the cause could be for that, but: • this looks like a bug in busybox which provides the date implementation, so you could report this problem to then : : On Fri, Sep 14, 2018 at 4:19 AM Kenneth Lee <kleewm@gmail.com> wrote: Hi Calin, There’s something not quite right with the “date” command in the MotionEye OS. I try to set the day to the current date but the resultant year keeps increasing by 1 each time I do a “date –s” [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20190818 [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20200818 [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20210818 [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20220818 [root@meye-09f2c071 etc]# date +%Y%m%d -s 20180914 20230818 [root@meye-09f2c071 etc]# Rgds Kenneth
'20180914' does not mean what you think it means. At least for busybox: $ date --help BusyBox v1.30.0.git (2018-08-01 13:57:11 CEST) multi-call binary. Usage: date [OPTIONS] [+FMT] [TIME] Display time (using +FMT), or set time [-s,--set] TIME Set time to TIME -u,--utc Work in UTC (don't convert to local time) -R,--rfc-2822 Output RFC-2822 compliant date string -I[SPEC] Output ISO-8601 compliant date string SPEC='date' (default) for date only, 'hours', 'minutes', or 'seconds' for date and time to the indicated precision -r,--reference FILE Display last modification time of FILE -d,--date TIME Display TIME, not 'now' -D FMT Use FMT for -d TIME conversion Recognized TIME formats: hh:mm[:ss] [YYYY.]MM.DD-hh:mm[:ss] YYYY-MM-DD hh:mm[:ss] [[[[[YY]YY]MM]DD]hh]mm[.ss] 20180914 matches only MMDDhhmm pattern.
Fixed: commit 76832ff5c4f107f8a8165fcafc9b05a888cdb964 Date: Sun Sep 23 20:27:32 2018 +0200 date: do not allow "month #20" and such, closes 11356 function old new delta parse_datestr 906 961 +55 Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com> diff --git a/libbb/time.c b/libbb/time.c index 82e6cb172..f9b8da0b3 100644 --- a/libbb/time.c +++ b/libbb/time.c @@ -184,6 +184,7 @@ void FAST_FUNC parse_datestr(const char *date_str, struct tm *ptm) ptm->tm_year -= 1900; /* Adjust years */ ptm->tm_mon -= 1; /* Adjust month from 1-12 to 0-11 */ } else { + err: bb_error_msg_and_die(bb_msg_invalid_date, date_str); } ptm->tm_sec = 0; /* assume zero if [.SS] is not given */ @@ -194,6 +195,19 @@ void FAST_FUNC parse_datestr(const char *date_str, struct tm *ptm) end = '\0'; /* else end != NUL and we error out */ } + /* Users were confused by "date -s 20180923" + * working (not in the way they were expecting). + * It was interpreted as MMDDhhmm, and not bothered by + * "month #20" in the least. Prevent such cases: + */ + if (ptm->tm_sec > 60 /* allow "23:60" leap second */ + || ptm->tm_min > 59 + || ptm->tm_hour > 23 + || ptm->tm_mday > 31 + || ptm->tm_mon > 11 /* month# is 0..11, not 1..12 */ + ) { + goto err; + }