{
    "mode": "info",
    "parameter": "date",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/info/date/json",
    "generated": "2026-11-10T12:41:20Z",
    "sections": {
        "File: coreutils.info,  Node: date invocation,  Next: arch invocation,  Up: System context": {
            "content": "",
            "subsections": [
                {
                    "name": "21.1 'date': Print or set system date and time",
                    "content": "Synopses:\n\ndate [OPTION]... [+FORMAT]\ndate [-u|--utc|--universal] [ MMDDhhmm[[CC]YY][.ss] ]\n\nThe 'date' command displays the date and time.  With the '--set'\n('-s') option, or with 'MMDDhhmm[[CC]YY][.ss]', it sets the date and\ntime.\n\nInvoking 'date' with no FORMAT argument is equivalent to invoking it\nwith a default format that depends on the 'LCTIME' locale category.  In\nthe default C locale, this format is ''+%a %b %e %H:%M:%S %Z %Y'', so\nthe output looks like 'Thu Jul  9 17:00:00 EDT 2020'.\n\nNormally, 'date' uses the time zone rules indicated by the 'TZ'\nenvironment variable, or the system default rules if 'TZ' is not set.\n*Note Specifying the Time Zone with 'TZ': (libc)TZ Variable.\n\nAn exit status of zero indicates success, and a nonzero value\nindicates failure.\n\n* Menu:\n\n* Date format specifiers::         Used in 'date '+...''\n* Setting the time::               Changing the system clock.\n* Options for date::               Instead of the current time.\n* Date input formats::             Specifying date strings.\n* Examples of date::               Examples.\n"
                }
            ]
        },
        "File: coreutils.info,  Node: Date format specifiers,  Next: Setting the time,  Up: date invocation": {
            "content": "If given an argument that starts with a '+', 'date' prints the current\ndate and time (or the date and time specified by the '--date' option,\nsee below) in the format defined by that argument, which is similar to\nthat of the 'strftime' function.  Except for conversion specifiers,\nwhich start with '%', characters in the format string are printed\nunchanged.  The conversion specifiers are described below.\n\n* Menu:\n\n* Time conversion specifiers::     %[HIklMNpPrRsSTXzZ]\n* Date conversion specifiers::     %[aAbBcCdDeFgGhjmuUVwWxyY]\n* Literal conversion specifiers::  %[%nt]\n* Padding and other flags::        Pad with zeros, spaces, etc.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Time conversion specifiers,  Next: Date conversion specifiers,  Up: Date format specifiers": {
            "content": "21.1.1.1 Time conversion specifiers\n...................................\n\n'date' conversion specifiers related to times.\n\n'%H'\nhour ('00'...'23')\n'%I'\nhour ('01'...'12')\n'%k'\nhour, space padded (' 0'...'23'); equivalent to '%H'.  This is a\nGNU extension.\n'%l'\nhour, space padded (' 1'...'12'); equivalent to '%I'.  This is a\nGNU extension.\n'%M'\nminute ('00'...'59')\n'%N'\nnanoseconds ('000000000'...'999999999').  This is a GNU extension.\n'%p'\nlocale's equivalent of either 'AM' or 'PM'; blank in many locales.\nNoon is treated as 'PM' and midnight as 'AM'.\n'%P'\nlike '%p', except lower case.  This is a GNU extension.\n'%r'\nlocale's 12-hour clock time (e.g., '11:11:04 PM')\n'%R'\n24-hour hour and minute.  Same as '%H:%M'.\n'%s'\nseconds since the Epoch, i.e., since 1970-01-01 00:00 UTC.  Leap\nseconds are not counted unless leap second support is available.\n*Note %s-examples::, for examples.  This is a GNU extension.\n'%S'\nsecond ('00'...'60').  This may be '60' if leap seconds are\nsupported.\n'%T'\n24-hour hour, minute, and second.  Same as '%H:%M:%S'.\n'%X'\nlocale's time representation (e.g., '23:13:48')\n'%z'\nFour-digit numeric time zone, e.g., '-0600' or '+0530', or '-0000'\nif no time zone is determinable.  This value reflects the numeric\ntime zone appropriate for the current time, using the time zone\nrules specified by the 'TZ' environment variable.  A time zone is\nnot determinable if its numeric offset is zero and its abbreviation\nbegins with '-'.  The time (and optionally, the time zone rules)\ncan be overridden by the '--date' option.\n'%:z'\nNumeric time zone with ':', e.g., '-06:00' or '+05:30'), or\n'-00:00' if no time zone is determinable.  This is a GNU extension.\n'%::z'\nNumeric time zone to the nearest second with ':' (e.g., '-06:00:00'\nor '+05:30:00'), or '-00:00:00' if no time zone is determinable.\nThis is a GNU extension.\n'%:::z'\nNumeric time zone with ':' using the minimum necessary precision\n(e.g., '-06', '+05:30', or '-04:56:02'), or '-00' if no time zone\nis determinable.  This is a GNU extension.\n'%Z'\nalphabetic time zone abbreviation (e.g., 'EDT'), or nothing if no\ntime zone is determinable.  See '%z' for how it is determined.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Date conversion specifiers,  Next: Literal conversion specifiers,  Prev: Time conversion specifiers,  Up: Date format specifiers": {
            "content": "21.1.1.2 Date conversion specifiers\n...................................\n\n'date' conversion specifiers related to dates.\n\n'%a'\nlocale's abbreviated weekday name (e.g., 'Sun')\n'%A'\nlocale's full weekday name, variable length (e.g., 'Sunday')\n'%b'\nlocale's abbreviated month name (e.g., 'Jan')\n'%B'\nlocale's full month name, variable length (e.g., 'January')\n'%c'\nlocale's date and time (e.g., 'Thu Mar  3 23:05:25 2020')\n'%C'\ncentury.  This is like '%Y', except the last two digits are\nomitted.  For example, it is '20' if '%Y' is '2019', and is '-0' if\n'%Y' is '-001'.  It is normally at least two characters, but it may\nbe more.\n'%d'\nday of month (e.g., '01')\n'%D'\ndate; same as '%m/%d/%y'\n'%e'\nday of month, space padded; same as '%d'\n'%F'\nfull date in ISO 8601 format; like '%+4Y-%m-%d' except that any\nflags or field width override the '+' and (after subtracting 6) the\n'4'.  This is a good choice for a date format, as it is standard\nand is easy to sort in the usual case where years are in the range\n0000...9999.\n'%g'\nyear corresponding to the ISO week number, but without the century\n(range '00' through '99').  This has the same format and value as\n'%y', except that if the ISO week number (see '%V') belongs to the\nprevious or next year, that year is used instead.\n'%G'\nyear corresponding to the ISO week number.  This has the same\nformat and value as '%Y', except that if the ISO week number (see\n'%V') belongs to the previous or next year, that year is used\ninstead.  It is normally useful only if '%V' is also used; for\nexample, the format '%G-%m-%d' is probably a mistake, since it\ncombines the ISO week number year with the conventional month and\nday.\n'%h'\nsame as '%b'\n'%j'\nday of year ('001'...'366')\n'%m'\nmonth ('01'...'12')\n'%q'\nquarter of year ('1'...'4')\n'%u'\nday of week ('1'...'7') with '1' corresponding to Monday\n'%U'\nweek number of year, with Sunday as the first day of the week\n('00'...'53').  Days in a new year preceding the first Sunday are\nin week zero.\n'%V'\nISO week number, that is, the week number of year, with Monday as\nthe first day of the week ('01'...'53').  If the week containing\nJanuary 1 has four or more days in the new year, then it is\nconsidered week 1; otherwise, it is week 53 of the previous year,\nand the next week is week 1.  (See the ISO 8601 standard.)\n'%w'\nday of week ('0'...'6') with 0 corresponding to Sunday\n'%W'\nweek number of year, with Monday as first day of week\n('00'...'53').  Days in a new year preceding the first Monday are\nin week zero.\n'%x'\nlocale's date representation (e.g., '12/31/99')\n'%y'\nlast two digits of year ('00'...'99')\n'%Y'\nyear.  This is normally at least four characters, but it may be\nmore.  Year '0000' precedes year '0001', and year '-001' precedes\nyear '0000'.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Literal conversion specifiers,  Next: Padding and other flags,  Prev: Date conversion specifiers,  Up: Date format specifiers": {
            "content": "21.1.1.3 Literal conversion specifiers\n......................................\n\n'date' conversion specifiers that produce literal strings.\n\n'%%'\na literal %\n'%n'\na newline\n'%t'\na horizontal tab\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Padding and other flags,  Prev: Literal conversion specifiers,  Up: Date format specifiers": {
            "content": "21.1.1.4 Padding and other flags\n................................\n",
            "subsections": []
        },
        "Unless otherwise specified, 'date' normally pads numeric fields with": {
            "content": "zeros, so that, for example, numeric months are always output as two\ndigits.  Most numeric fields are padded on the left.  However,\nnanoseconds are padded on the right since they are commonly used after\ndecimal points in formats like '%s.%-N'.  Also, seconds since the Epoch\nare not padded since there is no natural width for them.\n\nThe following optional flags can appear after the '%':\n\n'-'\n(hyphen) Do not pad the field; useful if the output is intended for\nhuman consumption.  This is a GNU extension.  As a special case,\n'%-N' outputs only enough trailing digits to not lose information,\nassuming that the timestamp's resolution is the same as the current\nhardware clock.  For example, if the hardware clock resolution is 1\nmicrosecond, '%s.%-N' outputs something like '1640890100.395710'.\n\n''\n(underscore) Pad with spaces; useful if you need a fixed number of\ncharacters in the output, but zeros are too distracting.  This is a\nGNU extension.\n'0'\n(zero) Pad with zeros even if the conversion specifier would\nnormally pad with spaces.\n'+'\nPad with zeros, like '0'.  In addition, precede any year number\nwith '+' if it exceeds 9999 or if its field width exceeds 4;\nsimilarly, precede any century number with '+' if it exceeds 99 or\nif its field width exceeds 2.  This supports ISO 8601 formats for\ndates far in the future; for example, the command 'date\n--date=12019-02-25 +%+13F' outputs the string '+012019-02-25'.\n'^'\nUse upper case characters if possible.  This is a GNU extension.\n'#'\nUse opposite case characters if possible.  A field that is normally\nupper case becomes lower case, and vice versa.  This is a GNU\nextension.\n\nHere are some examples of padding:\n\ndate +%d/%m -d \"Feb 1\"\n=> 01/02\ndate +%-d/%-m -d \"Feb 1\"\n=> 1/2\ndate +%d/%m -d \"Feb 1\"\n=>  1/ 2\n\nYou can optionally specify the field width (after any flag, if\npresent) as a decimal number.  If the natural size of the output of the\nfield has less than the specified number of characters, the result is\nnormally written right adjusted and padded to the given size.  For\nexample, '%9B' prints the right adjusted month name in a field of width\n9.  Nanoseconds are left adjusted, and are truncated or padded to the\nfield width.\n\nAn optional modifier can follow the optional flag and width\nspecification.  The modifiers are:\n\n'E'\nUse the locale's alternate representation for date and time.  This\nmodifier applies to the '%c', '%C', '%x', '%X', '%y' and '%Y'\nconversion specifiers.  In a Japanese locale, for example, '%Ex'\nmight yield a date format based on the Japanese Emperors' reigns.\n\n'O'\nUse the locale's alternate numeric symbols for numbers.  This\nmodifier applies only to numeric conversion specifiers.\n\nIf the format supports the modifier but no alternate representation\nis available, it is ignored.\n\nPOSIX specifies the behavior of flags and field widths only for '%C',\n'%F', '%G', and '%Y' (all without modifiers), and requires a flag to be\npresent if and only if a field width is also present.  Other\ncombinations of flags, field widths and modifiers are GNU extensions.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Setting the time,  Next: Options for date,  Prev: Date format specifiers,  Up: date invocation": {
            "content": "",
            "subsections": []
        },
        "You must have appropriate privileges to set the system clock.  For": {
            "content": "changes to persist across a reboot, the hardware clock may need to be\nupdated from the system clock, which might not happen automatically on\nyour system.\n\nTo set the clock, you can use the '--set' ('-s') option (*note",
            "subsections": []
        },
        "Options for date::).  To set the clock without using GNU extensions, you": {
            "content": "can give 'date' an argument of the form 'MMDDhhmm[[CC]YY][.ss]' where\neach two-letter component stands for two digits with the following\nmeanings:\n\nMM\nmonth\nDD\nday within month\nHH\nhour\nMM\nminute\nCC\nfirst two digits of year (optional)\nYY\nlast two digits of year (optional)\nSS\nsecond (optional)\n\nNote, the '--date' and '--set' options may not be used with an\nargument in the above format.  The '--universal' option may be used with\nsuch an argument to indicate that the specified date and time are\nrelative to Universal Time rather than to the local time zone.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Options for date,  Next: Examples of date,  Prev: Setting the time,  Up: date invocation": {
            "content": "The program accepts the following options.  Also see *note Common\noptions::.  Except for '-u', these options are all GNU extensions to\nPOSIX.\n\nAll options that specify the date to display are mutually exclusive.\nI.e.: '--date', '--file', '--reference', '--resolution'.\n\n'-d DATESTR'\n'--date=DATESTR'\nDisplay the date and time specified in DATESTR instead of the\ncurrent date and time.  DATESTR can be in almost any common format.\nIt can contain month names, time zones, 'am' and 'pm', 'yesterday',\netc.  For example, '--date=\"2020-07-21 14:19:13.489392193 +0530\"'\nspecifies the instant of time that is 489,392,193 nanoseconds after\nJuly 21, 2020 at 2:19:13 PM in a time zone that is 5 hours and 30\nminutes east of UTC.\nNote: input currently must be in locale independent format.  E.g.,\nthe LCTIME=C below is needed to print back the correct date in\nmany locales:\ndate -d \"$(LCTIME=C date)\"\n*Note Date input formats::.\n\n'--debug'\nAnnotate the parsed date, display the effective time zone, and warn\nabout potential misuse.\n\n'-f DATEFILE'\n'--file=DATEFILE'\nParse each line in DATEFILE as with '-d' and display the resulting\ndate and time.  If DATEFILE is '-', use standard input.  This is\nuseful when you have many dates to process, because the system\noverhead of starting up the 'date' executable many times can be\nconsiderable.\n\n'-I[TIMESPEC]'\n'--iso-8601[=TIMESPEC]'\nDisplay the date using an ISO 8601 format, '%Y-%m-%d'.\n\nThe argument TIMESPEC specifies the number of additional terms of\nthe time to include.  It can be one of the following:\n'auto'\nPrint just the date.  This is the default if TIMESPEC is\nomitted.  This is like the format '%Y-%m-%d'.\n\n'hours'\nAlso print hours and time zone.  This is like the format\n'%Y-%m-%dT%H%:z'.\n\n'minutes'\nAlso print minutes.  This is like the format\n'%Y-%m-%dT%H:%M%:z'.\n\n'seconds'\nAlso print seconds.  This is like the format\n'%Y-%m-%dT%H:%M:%S%:z'.\n\n'ns'\nAlso print nanoseconds.  This is like the format\n'%Y-%m-%dT%H:%M:%S,%N%:z'.\n\nThis format is always suitable as input for the '--date' ('-d') and\n'--file' ('-f') options, regardless of the current locale.\n\n'-r FILE'\n'--reference=FILE'\nDisplay the date and time of the last modification of FILE, instead\nof the current date and time.\n\n'--resolution'\nDisplay the timestamp resolution instead of the time.  Current\nclock timestamps that are output by 'date' are integer multiples of\nthe timestamp resolution.  With this option, the format defaults to\n'%s.%N'.  For example, if the clock resolution is 1 millisecond,\nthe output is:\n\n0.001000000\n\n'-R'\n'--rfc-email'\nDisplay the date and time using the format '%a, %d %b %Y %H:%M:%S\n%z', evaluated in the C locale so abbreviations are always in\nEnglish.  For example:\n\nMon, 09 Jul 2020 17:00:00 -0400\n\nThis format conforms to Internet RFCs 5322\n(https://tools.ietf.org/search/rfc5322), 2822\n(https://tools.ietf.org/search/rfc2822) and 822\n(https://tools.ietf.org/search/rfc822), the current and previous\nstandards for Internet email.  For compatibility with older\nversions of 'date', '--rfc-2822' and '--rfc-822' are aliases for\n'--rfc-email'.\n\n'--rfc-3339=TIMESPEC'\nDisplay the date using a format specified by Internet RFC 3339\n(https://tools.ietf.org/search/rfc3339).  This is like\n'--iso-8601', except that a space rather than a 'T' separates dates\nfrom times, and a period rather than a comma separates seconds from\nsubseconds.  This format is always suitable as input for the\n'--date' ('-d') and '--file' ('-f') options, regardless of the\ncurrent locale.\n\nThe argument TIMESPEC specifies how much of the time to include.\nIt can be one of the following:\n\n'date'\nPrint just the full-date, e.g., '2020-07-21'.  This is like\nthe format '%Y-%m-%d'.\n\n'seconds'\nPrint the full-date and full-time separated by a space, e.g.,\n'2020-07-21 04:30:37+05:30'.  The output ends with a numeric\ntime-offset; here the '+05:30' means that local time is five\nhours and thirty minutes east of UTC.  This is like the format\n'%Y-%m-%d %H:%M:%S%:z'.\n\n'ns'\nLike 'seconds', but also print nanoseconds, e.g., '2020-07-21\n04:30:37.998458565+05:30'.  This is like the format '%Y-%m-%d\n%H:%M:%S.%N%:z'.\n\n'-s DATESTR'\n'--set=DATESTR'\nSet the date and time to DATESTR.  See '-d' above.  See also *note\nSetting the time::.\n\n'-u'\n'--utc'\n'--universal'\nUse Universal Time by operating as if the 'TZ' environment variable\nwere set to the string 'UTC0'.  UTC stands for Coordinated\nUniversal Time, established in 1960.  Universal Time is often\ncalled \"Greenwich Mean Time\" (GMT) for historical reasons.\nTypically, systems ignore leap seconds and thus implement an\napproximation to UTC rather than true UTC.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Date input formats,  Next: Version sort ordering,  Prev: File timestamps,  Up: Top": {
            "content": "",
            "subsections": []
        },
        "29 Date input formats": {
            "content": "First, a quote:\n\nOur units of temporal measurement, from seconds on up to months,\nare so complicated, asymmetrical and disjunctive so as to make\ncoherent mental reckoning in time all but impossible.  Indeed, had\nsome tyrannical god contrived to enslave our minds to time, to make\nit all but impossible for us to escape subjection to sodden\nroutines and unpleasant surprises, he could hardly have done better\nthan handing down our present system.  It is like a set of\ntrapezoidal building blocks, with no vertical or horizontal\nsurfaces, like a language in which the simplest thought demands\nornate constructions, useless particles and lengthy\ncircumlocutions.  Unlike the more successful patterns of language\nand science, which enable us to face experience boldly or at least\nlevel-headedly, our system of temporal calculation silently and\npersistently encourages our terror of time.\n\n... It is as though architects had to measure length in feet, width\nin meters and height in ells; as though basic instruction manuals\ndemanded a knowledge of five different languages.  It is no wonder\nthen that we often look into our own immediate past or future, last\nTuesday or a week from Sunday, with feelings of helpless confusion.\n...\n\n--Robert Grudin, 'Time and the Art of Living'.\n\nThis section describes the textual date representations that GNU\nprograms accept.  These are the strings you, as a user, can supply as\narguments to the various programs.  The C interface (via the\n'parsedatetime' function) is not described here.\n\n* Menu:\n\n* General date syntax::          Common rules\n* Calendar date items::          '14 Nov 2022'\n* Time of day items::            '9:02pm'\n* Time zone items::              'UTC', '-0700', '+0900', ...\n* Combined date and time of day items:: '2022-11-14T21:02:42,000000-0500'\n* Day of week items::            'Monday' and others\n* Relative items in date strings:: 'next tuesday, 2 years ago'\n* Pure numbers in date strings:: '20221114', '2102'\n* Seconds since the Epoch::      '@1668477762'\n* Specifying time zone rules::   'TZ=\"America/NewYork\"', 'TZ=\"UTC0\"'\n* Authors of parsedatetime::    Bellovin, Eggert, Salz, Berets, et al.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: General date syntax,  Next: Calendar date items,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.1 General date syntax",
                    "content": "A \"date\" is a string, possibly empty, containing many items separated by\nwhitespace.  The whitespace may be omitted when no ambiguity arises."
                }
            ]
        },
        "The empty string means the beginning of today (i.e., midnight).  Order": {
            "content": "of the items is immaterial.  A date string may contain many flavors of\nitems:\n\n* calendar date items\n* time of day items\n* time zone items\n* combined date and time of day items\n* day of the week items\n* relative items\n* pure numbers.\n\nWe describe each of these item types in turn, below.\n\nA few ordinal numbers may be written out in words in some contexts.",
            "subsections": []
        },
        "This is most useful for specifying day of the week items or relative": {
            "content": "items (see below).  Among the most commonly used ordinal numbers, the\nword 'last' stands for -1, 'this' stands for 0, and 'first' and 'next'\nboth stand for 1.  Because the word 'second' stands for the unit of time\nthere is no way to write the ordinal number 2, but for convenience\n'third' stands for 3, 'fourth' for 4, 'fifth' for 5, 'sixth' for 6,\n'seventh' for 7, 'eighth' for 8, 'ninth' for 9, 'tenth' for 10,\n'eleventh' for 11 and 'twelfth' for 12.\n\nWhen a month is written this way, it is still considered to be\nwritten numerically, instead of being \"spelled in full\"; this changes\nthe allowed strings.\n\nIn the current implementation, only English is supported for words\nand abbreviations like 'AM', 'DST', 'EST', 'first', 'January', 'Sunday',\n'tomorrow', and 'year'.\n\nThe output of the 'date' command is not always acceptable as a date\nstring, not only because of the language problem, but also because there\nis no standard meaning for time zone items like 'IST'.  When using\n'date' to generate a date string intended to be parsed later, specify a\ndate format that is independent of language and that does not use time\nzone items other than 'UTC' and 'Z'.  Here are some ways to do this:\n\n$ LCALL=C TZ=UTC0 date\nTue Nov 15 02:02:42 UTC 2022\n$ TZ=UTC0 date +'%Y-%m-%d %H:%M:%SZ'\n2022-11-15 02:02:42Z\n$ date --rfc-3339=ns  # --rfc-3339 is a GNU extension.\n2022-11-14 21:02:42.000000000-05:00\n$ date --rfc-email  # a GNU extension\nMon, 14 Nov 2022 21:02:42 -0500\n$ date +'%Y-%m-%d %H:%M:%S %z'  # %z is a GNU extension.\n2022-11-14 21:02:42 -0500\n$ date +'@%s.%N'  # %s and %N are GNU extensions.\n@1668477762.692722128\n\nAlphabetic case is completely ignored in dates.  Comments may be\nintroduced between round parentheses, as long as included parentheses\nare properly nested.  Hyphens not followed by a digit are currently\nignored.  Leading zeros on numbers are ignored.\n\nInvalid dates like '2022-02-29' or times like '24:00' are rejected.",
            "subsections": []
        },
        "In the typical case of a host that does not support leap seconds, a time": {
            "content": "like '23:59:60' is rejected even if it corresponds to a valid leap\nsecond.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Calendar date items,  Next: Time of day items,  Prev: General date syntax,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.2 Calendar date items",
                    "content": "A \"calendar date item\" specifies a day of the year.  It is specified\ndifferently, depending on whether the month is specified numerically or\nliterally.  All these strings specify the same calendar date:\n\n2022-11-14     # ISO 8601.\n22-11-14       # Assume 19xx for 69 through 99,\n# 20xx for 00 through 68 (not recommended).\n11/14/2022     # Common U.S. writing.\n14 November 2022\n14 Nov 2022    # Three-letter abbreviations always allowed.\nNovember 14, 2022\n14-nov-2022\n14nov2022\n\nThe year can also be omitted.  In this case, the last specified year\nis used, or the current year if none.  For example:\n\n11/14\nnov 14\n\nHere are the rules.\n\nFor numeric months, the ISO 8601 format 'YEAR-MONTH-DAY' is allowed,\nwhere YEAR is any positive number, MONTH is a number between 01 and 12,\nand DAY is a number between 01 and 31.  A leading zero must be present\nif a number is less than ten.  If YEAR is 68 or smaller, then 2000 is\nadded to it; otherwise, if YEAR is less than 100, then 1900 is added to\nit.  The construct 'MONTH/DAY/YEAR', popular in the United States, is\naccepted.  Also 'MONTH/DAY', omitting the year.\n\nLiteral months may be spelled out in full: 'January', 'February',\n'March', 'April', 'May', 'June', 'July', 'August', 'September',\n'October', 'November' or 'December'.  Literal months may be abbreviated\nto their first three letters, possibly followed by an abbreviating dot.\nIt is also permitted to write 'Sept' instead of 'September'.\n\nWhen months are written literally, the calendar date may be given as\nany of the following:\n\nDAY MONTH YEAR\nDAY MONTH\nMONTH DAY YEAR\nDAY-MONTH-YEAR\n\nOr, omitting the year:\n\nMONTH DAY\n"
                }
            ]
        },
        "File: coreutils.info,  Node: Time of day items,  Next: Time zone items,  Prev: Calendar date items,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.3 Time of day items",
                    "content": "A \"time of day item\" in date strings specifies the time on a given day.\nHere are some examples, all of which represent the same time:\n\n20:02:00.000000\n20:02\n8:02pm\n20:02-0500      # In EST (U.S. Eastern Standard Time).\n\nMore generally, the time of day may be given as 'HOUR:MINUTE:SECOND',\nwhere HOUR is a number between 0 and 23, MINUTE is a number between 0\nand 59, and SECOND is a number between 0 and 59 possibly followed by '.'\nor ',' and a fraction containing one or more digits.  Alternatively,\n':SECOND' can be omitted, in which case it is taken to be zero.  On the\nrare hosts that support leap seconds, SECOND may be 60.\n\nIf the time is followed by 'am' or 'pm' (or 'a.m.' or 'p.m.'), HOUR\nis restricted to run from 1 to 12, and ':MINUTE' may be omitted (taken\nto be zero).  'am' indicates the first half of the day, 'pm' indicates\nthe second half of the day.  In this notation, 12 is the predecessor of\n1: midnight is '12am' while noon is '12pm'.  (This is the zero-oriented\ninterpretation of '12am' and '12pm', as opposed to the old tradition\nderived from Latin which uses '12m' for noon and '12pm' for midnight.)\n\nThe time may alternatively be followed by a time zone correction,\nexpressed as 'SHHMM', where S is '+' or '-', HH is a number of zone\nhours and MM is a number of zone minutes.  The zone minutes term, MM,\nmay be omitted, in which case the one- or two-digit correction is\ninterpreted as a number of hours.  You can also separate HH from MM with\na colon.  When a time zone correction is given this way, it forces\ninterpretation of the time relative to Coordinated Universal Time (UTC),\noverriding any previous specification for the time zone or the local\ntime zone.  For example, '+0530' and '+05:30' both stand for the time\nzone 5.5 hours ahead of UTC (e.g., India).  This is the best way to\nspecify a time zone correction by fractional parts of an hour.  The\nmaximum zone correction is 24 hours.\n\nEither 'am'/'pm' or a time zone correction may be specified, but not\nboth.\n"
                }
            ]
        },
        "File: coreutils.info,  Node: Time zone items,  Next: Combined date and time of day items,  Prev: Time of day items,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.4 Time zone items",
                    "content": "A \"time zone item\" specifies an international time zone, indicated by a\nsmall set of letters, e.g., 'UTC' or 'Z' for Coordinated Universal Time."
                }
            ]
        },
        "Any included periods are ignored.  By following a non-daylight-saving": {
            "content": "time zone by the string 'DST' in a separate word (that is, separated by\nsome white space), the corresponding daylight saving time zone may be\nspecified.  Alternatively, a non-daylight-saving time zone can be\nfollowed by a time zone correction, to add the two values.  This is\nnormally done only for 'UTC'; for example, 'UTC+05:30' is equivalent to\n'+05:30'.\n\nTime zone items other than 'UTC' and 'Z' are obsolescent and are not\nrecommended, because they are ambiguous; for example, 'EST' has a\ndifferent meaning in Australia than in the United States, and 'A' has\ndifferent meaning as a military time zone than as an obsolete RFC 822\ntime zone.  Instead, it's better to use unambiguous numeric time zone\ncorrections like '-0500', as described in the previous section.\n\nIf neither a time zone item nor a time zone correction is supplied,\ntimestamps are interpreted using the rules of the default time zone\n(*note Specifying time zone rules::).\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Combined date and time of day items,  Next: Day of week items,  Prev: Time zone items,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.5 Combined date and time of day items",
                    "content": ""
                }
            ]
        },
        "The ISO 8601 date and time of day extended format consists of an ISO": {
            "content": "8601 date, a 'T' character separator, and an ISO 8601 time of day.  This\nformat is also recognized if the 'T' is replaced by a space.\n\nIn this format, the time of day should use 24-hour notation.",
            "subsections": []
        },
        "Fractional seconds are allowed, with either comma or period preceding": {
            "content": "the fraction.  ISO 8601 fractional minutes and hours are not supported.",
            "subsections": []
        },
        "Typically, hosts support nanosecond timestamp resolution; excess": {
            "content": "precision is silently discarded.\n\nHere are some examples:\n\n2022-09-24T20:02:00.052-05:00\n2022-12-31T23:59:59,999999999+11:00\n1970-01-01 00:00Z\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Day of week items,  Next: Relative items in date strings,  Prev: Combined date and time of day items,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.6 Day of week items",
                    "content": ""
                }
            ]
        },
        "The explicit mention of a day of the week will forward the date (only if": {
            "content": "necessary) to reach that day of the week in the future.\n\nDays of the week may be spelled out in full: 'Sunday', 'Monday',\n'Tuesday', 'Wednesday', 'Thursday', 'Friday' or 'Saturday'.  Days may be\nabbreviated to their first three letters, optionally followed by a\nperiod.  The special abbreviations 'Tues' for 'Tuesday', 'Wednes' for\n'Wednesday' and 'Thur' or 'Thurs' for 'Thursday' are also allowed.\n\nA number may precede a day of the week item to move forward\nsupplementary weeks.  It is best used in expression like 'third monday'.",
            "subsections": []
        },
        "In this context, 'last DAY' or 'next DAY' is also acceptable; they move": {
            "content": "one week before or after the day that DAY by itself would represent.\n\nA comma following a day of the week item is ignored.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Relative items in date strings,  Next: Pure numbers in date strings,  Prev: Day of week items,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.7 Relative items in date strings",
                    "content": "\"Relative items\" adjust a date (or the current date if none) forward or\nbackward.  The effects of relative items accumulate.  Here are some\nexamples:\n\n1 year\n1 year ago\n3 years\n2 days\n\nThe unit of time displacement may be selected by the string 'year' or\n'month' for moving by whole years or months.  These are fuzzy units, as\nyears and months are not all of equal duration.  More precise units are\n'fortnight' which is worth 14 days, 'week' worth 7 days, 'day' worth 24\nhours, 'hour' worth 60 minutes, 'minute' or 'min' worth 60 seconds, and\n'second' or 'sec' worth one second.  An 's' suffix on these units is\naccepted and ignored.\n\nThe unit of time may be preceded by a multiplier, given as an\noptionally signed number.  Unsigned numbers are taken as positively\nsigned.  No number at all implies 1 for a multiplier.  Following a\nrelative item by the string 'ago' is equivalent to preceding the unit by\na multiplier with value -1.\n\nThe string 'tomorrow' is worth one day in the future (equivalent to\n'day'), the string 'yesterday' is worth one day in the past (equivalent\nto 'day ago').\n\nThe strings 'now' or 'today' are relative items corresponding to\nzero-valued time displacement, these strings come from the fact a\nzero-valued time displacement represents the current time when not\notherwise changed by previous items.  They may be used to stress other\nitems, like in '12:00 today'.  The string 'this' also has the meaning of\na zero-valued time displacement, but is preferred in date strings like\n'this thursday'.\n\nWhen a relative item causes the resulting date to cross a boundary\nwhere the clocks were adjusted, typically for daylight saving time, the\nresulting date and time are adjusted accordingly.\n\nThe fuzz in units can cause problems with relative items.  For\nexample, '2022-12-31 -1 month' might evaluate to 2022-12-01, because\n2022-11-31 is an invalid date.  To determine the previous month more\nreliably, you can ask for the month before the 15th of the current\nmonth.  For example:\n\n$ date -R\nThu, 31 Dec 2022 13:02:39 -0400\n$ date --date='-1 month' +'Last month was %B?'\nLast month was December?\n$ date --date=\"$(date +%Y-%m-15) -1 month\" +'Last month was %B!'\nLast month was November!\n\nAlso, take care when manipulating dates around clock changes such as\ndaylight saving leaps.  In a few cases these have added or subtracted as\nmuch as 24 hours from the clock, so it is often wise to adopt universal\ntime by setting the 'TZ' environment variable to 'UTC0' before embarking\non calendrical calculations.\n"
                }
            ]
        },
        "File: coreutils.info,  Node: Pure numbers in date strings,  Next: Seconds since the Epoch,  Prev: Relative items in date strings,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.8 Pure numbers in date strings",
                    "content": ""
                }
            ]
        },
        "The precise interpretation of a pure decimal number depends on the": {
            "content": "context in the date string.\n\nIf the decimal number is of the form YYYYMMDD and no other calendar\ndate item (*note Calendar date items::) appears before it in the date\nstring, then YYYY is read as the year, MM as the month number and DD as\nthe day of the month, for the specified calendar date.\n\nIf the decimal number is of the form HHMM and no other time of day\nitem appears before it in the date string, then HH is read as the hour\nof the day and MM as the minute of the hour, for the specified time of\nday.  MM can also be omitted.\n\nIf both a calendar date and a time of day appear to the left of a\nnumber in the date string, but no relative item, then the number\noverrides the year.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Seconds since the Epoch,  Next: Specifying time zone rules,  Prev: Pure numbers in date strings,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.9 Seconds since the Epoch",
                    "content": "If you precede a number with '@', it represents an internal timestamp as\na count of seconds.  The number can contain an internal decimal point\n(either '.' or ','); any excess precision not supported by the internal\nrepresentation is truncated toward minus infinity.  Such a number cannot\nbe combined with any other date item, as it specifies a complete\ntimestamp.\n\nInternally, computer times are represented as a count of seconds\nsince an Epoch--a well-defined point of time.  On GNU and POSIX systems,\nthe Epoch is 1970-01-01 00:00:00 UTC, so '@0' represents this time, '@1'\nrepresents 1970-01-01 00:00:01 UTC, and so forth.  GNU and most other\nPOSIX-compliant systems support such times as an extension to POSIX,\nusing negative counts, so that '@-1' represents 1969-12-31 23:59:59 UTC.\n\nMost modern systems count seconds with 64-bit two's-complement\nintegers of seconds with nanosecond subcounts, which is a range that\nincludes the known lifetime of the universe with nanosecond resolution."
                }
            ]
        },
        "Some obsolescent systems count seconds with 32-bit two's-complement": {
            "content": "integers and can represent times from 1901-12-13 20:45:52 through\n2038-01-19 03:14:07 UTC.  A few systems sport other time ranges.\n\nOn most hosts, these counts ignore the presence of leap seconds.  For\nexample, on most hosts '@1483228799' represents 2016-12-31 23:59:59 UTC,\n'@1483228800' represents 2017-01-01 00:00:00 UTC, and there is no way to\nrepresent the intervening leap second 2016-12-31 23:59:60 UTC.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Specifying time zone rules,  Next: Authors of parsedatetime,  Prev: Seconds since the Epoch,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.10 Specifying time zone rules",
                    "content": ""
                }
            ]
        },
        "Normally, dates are interpreted using the rules of the current time": {
            "content": "zone, which in turn are specified by the 'TZ' environment variable, or\nby a system default if 'TZ' is not set.  To specify a different set of\ndefault time zone rules that apply just to one date, start the date with\na string of the form 'TZ=\"RULE\"'.  The two quote characters ('\"') must\nbe present in the date, and any quotes or backslashes within RULE must\nbe escaped by a backslash.\n\nFor example, with the GNU 'date' command you can answer the question\n\"What time is it in New York when a Paris clock shows 6:30am on October\n31, 2022?\" by using a date beginning with 'TZ=\"Europe/Paris\"' as shown\nin the following shell transcript:\n\n$ export TZ=\"America/NewYork\"\n$ date --date='TZ=\"Europe/Paris\" 2022-10-31 06:30'\nMon Oct 31 01:30:00 EDT 2022\n\nIn this example, the '--date' operand begins with its own 'TZ'\nsetting, so the rest of that operand is processed according to\n'Europe/Paris' rules, treating the string '2022-11-14 06:30' as if it\nwere in Paris.  However, since the output of the 'date' command is\nprocessed according to the overall time zone rules, it uses New York\ntime.  (Paris was normally six hours ahead of New York in 2022, but this\nexample refers to a brief Halloween period when the gap was five hours.)\n\nA 'TZ' value is a rule that typically names a location in the 'tz'\ndatabase (https://www.iana.org/time-zones).  A recent catalog of\nlocation names appears in the TWiki Date and Time Gateway\n(https://twiki.org/cgi-bin/xtra/tzdatepick.html).  A few non-GNU hosts\nrequire a colon before a location name in a 'TZ' setting, e.g.,\n'TZ=\":America/NewYork\"'.\n\nThe 'tz' database includes a wide variety of locations ranging from\n'Africa/Abidjan' to 'Pacific/Tongatapu', but if you are at sea and have\nyour own private time zone, or if you are using a non-GNU host that does\nnot support the 'tz' database, you may need to use a POSIX rule instead.",
            "subsections": []
        },
        "The previously-mentioned POSIX rule 'UTC0' says that the time zone": {
            "content": "abbreviation is 'UTC', the zone is zero hours away from Greenwich, and\nthere is no daylight saving time.  POSIX rules can also specify nonzero",
            "subsections": []
        },
        "Greenwich offsets.  For example, the following shell transcript answers": {
            "content": "the question \"What time is it five and a half hours east of Greenwich\nwhen a clock seven hours west of Greenwich shows 9:50pm on July 12,\n2022?\"\n\n$ TZ=\"<+0530>-5:30\" date --date='TZ=\"<-07>+7\" 2022-07-12 21:50'\nWed Jul 13 10:20:00 +0530 2022\n\nThis example uses the somewhat-confusing POSIX convention for rules.\n'TZ=\"<-07>+7\"' says that the time zone abbreviation is '-07' and the\ntime zone is 7 hours west of Greenwich, and 'TZ=\"<+0530>-5:30\"' says\nthat the time zone abbreviation is '+0530' and the time zone is 5 hours\n30 minutes east of Greenwich.  (One should never use a setting like\n'TZ=\"UTC-5\"', since this would incorrectly imply that local time is five\nhours east of Greenwich and the time zone is called \"UTC\".)  Although\ntrickier POSIX 'TZ' settings like 'TZ=\"<-05>+5<-04>,M3.2.0/2,M11.1.0/2\"'\ncan specify some daylight saving regimes, location-based settings like\n'TZ=\"America/NewYork\"' are typically simpler and more accurate\nhistorically.  *Note Specifying the Time Zone with 'TZ': (libc)TZ\nVariable.\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Authors of parsedatetime,  Prev: Specifying time zone rules,  Up: Date input formats": {
            "content": "",
            "subsections": [
                {
                    "name": "29.11 Authors of 'parsedatetime'",
                    "content": "'parsedatetime' started life as 'getdate', as originally implemented by\nSteven M. Bellovin (<smb@research.att.com>) while at the University of"
                }
            ]
        },
        "North Carolina at Chapel Hill.  The code was later tweaked by a couple": {
            "content": "of people on Usenet, then completely overhauled by Rich $alz\n(<rsalz@bbn.com>) and Jim Berets (<jberets@bbn.com>) in August, 1990.",
            "subsections": []
        },
        "Various revisions for the GNU system were made by David MacKenzie, Jim": {
            "content": "",
            "subsections": []
        },
        "Meyering, Paul Eggert and others, including renaming it to 'getdate' to": {
            "content": "avoid a conflict with the alternative Posix function 'getdate', and a\nlater rename to 'parsedatetime'.  The Posix function 'getdate' can\nparse more locale-specific dates using 'strptime', but relies on an\nenvironment variable and external file, and lacks the thread-safety of\n'parsedatetime'.\n\nThis chapter was originally produced by Franc,ois Pinard\n(<pinard@iro.umontreal.ca>) from the 'parsedatetime.y' source code, and\nthen edited by K. Berry (<kb@cs.umb.edu>).\n",
            "subsections": []
        },
        "File: coreutils.info,  Node: Examples of date,  Prev: Options for date,  Up: date invocation": {
            "content": "",
            "subsections": []
        },
        "Here are a few examples.  Also see the documentation for the '-d' option": {
            "content": "in the previous section.\n\n* To print the date of the day before yesterday:\n\ndate --date='2 days ago'\n\n* To print the date of the day three months and one day hence:\n\ndate --date='3 months 1 day'\n\n* To print the day of year of Christmas in the current year:\n\ndate --date='25 Dec' +%j\n\n* To print the current full month name and the day of the month:\n\ndate '+%B %d'\n\nBut this may not be what you want because for the first nine days\nof the month, the '%d' expands to a zero-padded two-digit field,\nfor example 'date -d 1may '+%B %d'' will print 'May 01'.\n\n* To print a date without the leading zero for one-digit days of the\nmonth, you can use the (GNU extension) '-' flag to suppress the\npadding altogether:\n\ndate -d 1may '+%B %-d'\n\n* To print the current date and time in the format required by many\nnon-GNU versions of 'date' when setting the system clock:\n\ndate +%m%d%H%M%Y.%S\n\n* To set the system clock forward by two minutes:\n\ndate --set='+2 minutes'\n\n* To print the date in Internet RFC 5322 format, use 'date\n--rfc-email'.  Here is some example output:\n\nTue, 09 Jul 2020 19:00:37 -0400\n\n* To convert a date string to the number of seconds since the Epoch\n(which is 1970-01-01 00:00 UTC), use the '--date' option with the\n'%s' format.  That can be useful in sorting and/or graphing and/or\ncomparing data by date.  The following command outputs the number\nof the seconds since the Epoch for the time two minutes after the\nEpoch:\n\ndate --date='1970-01-01 00:02:00 +0000' +%s\n120\n\nTo convert a date string from one time zone FROM to another TO,\nspecify 'TZ=\"FROM\"' in the environment and 'TZ=\"TO\"' in the\n'--date' option.  *Note Specifying time zone rules::.  For example:\n\nTZ=\"Asia/Tokyo\" date --date='TZ=\"America/NewYork\" 2023-05-07 12:23'\nMon May  8 01:23:00 JST 2023\n\nIf you do not specify time zone information in the date string,\n'date' uses your computer's idea of the time zone when interpreting\nthe string.  For example, if your computer's time zone is that of\nCambridge, Massachusetts, which was then 5 hours (i.e., 18,000\nseconds) behind UTC:\n\n# local time zone used\ndate --date='1970-01-01 00:02:00' +%s\n18120\n\n* If you're sorting or graphing dated data, your raw date values may\nbe represented as seconds since the Epoch.  But few people can look\nat the date '1577836800' and casually note \"Oh, that's the first\nsecond of the year 2020 in Greenwich, England.\"\n\ndate --date='2020-01-01 UTC' +%s\n1577836800\n\nAn alternative is to use the '--utc' ('-u') option.  Then you may\nomit 'UTC' from the date string.  Although this produces the same\nresult for '%s' and many other format sequences, with a time zone\noffset different from zero, it would give a different result for\nzone-dependent formats like '%z'.\n\ndate -u --date=2020-07-21 +%s\n1595289600\n\nTo convert such an unwieldy number of seconds back to a more\nreadable form, use a command like this:\n\ndate -d @1595289600 +\"%F %T %z\"\n2020-07-20 20:00:00 -0400\n\nOften it is better to output UTC-relative date and time:\n\ndate -u -d @1595289600 +\"%F %T %z\"\n2020-07-21 00:00:00 +0000\n\n* Typically the seconds count omits leap seconds, but some systems\nare exceptions.  Because leap seconds are not predictable, the\nmapping between the seconds count and a future timestamp is not\nreliable on the atypical systems that include leap seconds in their\ncounts.\n\nHere is how the two kinds of systems handle the leap second at the\nend of the year 2016:\n\n# Typical systems ignore leap seconds:\ndate --date='2016-12-31 23:59:59 +0000' +%s\n1483228799\ndate --date='2016-12-31 23:59:60 +0000' +%s\ndate: invalid date '2016-12-31 23:59:60 +0000'\ndate --date='2017-01-01 00:00:00 +0000' +%s\n1483228800\n\n# Atypical systems count leap seconds:\ndate --date='2016-12-31 23:59:59 +0000' +%s\n1483228825\ndate --date='2016-12-31 23:59:60 +0000' +%s\n1483228826\ndate --date='2017-01-01 00:00:00 +0000' +%s\n1483228827\n",
            "subsections": []
        }
    },
    "flags": [],
    "examples": [],
    "see_also": []
}