{ "content": [ { "type": "text", "text": "# date (info)\n\n## Sections\n\n- **29 Date input formats** (11 subsections)\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "date", "section": "", "mode": "info", "summary": null, "synopsis": null, "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "29 Date input formats", "lines": 47, "subsections": [ { "name": "29.1 General date syntax", "lines": 66 }, { "name": "29.2 Calendar date items", "lines": 52 }, { "name": "29.3 Time of day items", "lines": 41 }, { "name": "29.4 Time zone items", "lines": 23 }, { "name": "29.5 Combined date and time of day items", "lines": 18 }, { "name": "29.6 Day of week items", "lines": 18 }, { "name": "29.7 Relative items in date strings", "lines": 60 }, { "name": "29.8 Pure numbers in date strings", "lines": 19 }, { "name": "29.9 Seconds since the Epoch", "lines": 27 }, { "name": "29.10 Specifying time zone rules", "lines": 43 }, { "name": "29.11 Authors of 'parsedatetime'", "lines": 143 } ] } ], "sections": { "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:: 19 Dec 1994.\n* Time of day items:: 9:20pm.\n* Time zone items:: EST, PDT, UTC, ...\n* Combined date and time of day items:: 1972-09-24T20:02:00,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:: 19931219, 1440.\n* Seconds since the Epoch:: @1078100502.\n* Specifying time zone rules:: TZ=\"America/NewYork\", TZ=\"UTC0\".\n* Authors of parsedatetime:: Bellovin, Eggert, Salz, Berets, et al.\n\nFile: coreutils.info, Node: General date syntax, Next: Calendar date items, Up: Date input formats\n", "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.\nThe empty string means the beginning of today (i.e., midnight). Order\nof 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.\nThis is most useful for specifying day of the week items or relative\nitems (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\nMon Mar 1 00:21:42 UTC 2004\n$ TZ=UTC0 date +'%Y-%m-%d %H:%M:%SZ'\n2004-03-01 00:21:42Z\n$ date --rfc-3339=ns # --rfc-3339 is a GNU extension.\n2004-02-29 16:21:42.692722128-08:00\n$ date --rfc-2822 # a GNU extension\nSun, 29 Feb 2004 16:21:42 -0800\n$ date +'%Y-%m-%d %H:%M:%S %z' # %z is a GNU extension.\n2004-02-29 16:21:42 -0800\n$ date +'@%s.%N' # %s and %N are GNU extensions.\n@1078100502.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 '2005-02-29' or times like '24:00' are rejected.\nIn the typical case of a host that does not support leap seconds, a time\nlike '23:59:60' is rejected even if it corresponds to a valid leap\nsecond.\n\nFile: coreutils.info, Node: Calendar date items, Next: Time of day items, Prev: General date syntax, Up: Date input formats\n" }, { "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\n1972-09-24 # ISO 8601.\n72-9-24 # Assume 19xx for 69 through 99,\n# 20xx for 00 through 68.\n72-09-24 # Leading zeros are ignored.\n9/24/72 # Common U.S. writing.\n24 September 1972\n24 Sept 72 # September has a special abbreviation.\n24 Sep 72 # Three-letter abbreviations always allowed.\nSep 24, 1972\n24-sep-72\n24sep72\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\n9/24\nsep 24\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\nFile: coreutils.info, Node: Time of day items, Next: Time zone items, Prev: Calendar date items, Up: Date input formats\n" }, { "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\nFile: coreutils.info, Node: Time zone items, Next: Combined date and time of day items, Prev: Time of day items, Up: Date input formats\n" }, { "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.\nAny included periods are ignored. By following a non-daylight-saving\ntime 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 obsolescent 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\nFile: coreutils.info, Node: Combined date and time of day items, Next: Day of week items, Prev: Time zone items, Up: Date input formats\n" }, { "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\n8601 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.\nFractional seconds are allowed, with either comma or period preceding\nthe fraction. ISO 8601 fractional minutes and hours are not supported.\nTypically, hosts support nanosecond timestamp resolution; excess\nprecision is silently discarded.\n\nHere are some examples:\n\n2012-09-24T20:02:00.052-05:00\n2012-12-31T23:59:59,999999999+11:00\n1970-01-01 00:00Z\n\nFile: 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\n" }, { "name": "29.6 Day of week items", "content": "The explicit mention of a day of the week will forward the date (only if\nnecessary) 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'.\nIn this context, 'last DAY' or 'next DAY' is also acceptable; they move\none 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\nFile: coreutils.info, Node: Relative items in date strings, Next: Pure numbers in date strings, Prev: Day of week items, Up: Date input formats\n" }, { "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, '2003-07-31 -1 month' might evaluate to 2003-07-01, because\n2003-06-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 Jul 2003 13:02:39 -0700\n$ date --date='-1 month' +'Last month was %B?'\nLast month was July?\n$ date --date=\"$(date +%Y-%m-15) -1 month\" +'Last month was %B!'\nLast month was June!\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\nFile: coreutils.info, Node: Pure numbers in date strings, Next: Seconds since the Epoch, Prev: Relative items in date strings, Up: Date input formats\n" }, { "name": "29.8 Pure numbers in date strings", "content": "The precise interpretation of a pure decimal number depends on the\ncontext 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\nFile: coreutils.info, Node: Seconds since the Epoch, Next: Specifying time zone rules, Prev: Pure numbers in date strings, Up: Date input formats\n" }, { "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\nTraditional Unix systems count seconds with 32-bit two's-complement\nintegers and can represent times from 1901-12-13 20:45:52 through\n2038-01-19 03:14:07 UTC. More modern systems use 64-bit counts of\nseconds with nanosecond subcounts, and can represent all the times in\nthe known lifetime of the universe to a resolution of 1 nanosecond.\n\nOn most hosts, these counts ignore the presence of leap seconds. For\nexample, on most hosts '@915148799' represents 1998-12-31 23:59:59 UTC,\n'@915148800' represents 1999-01-01 00:00:00 UTC, and there is no way to\nrepresent the intervening leap second 1998-12-31 23:59:60 UTC.\n\nFile: coreutils.info, Node: Specifying time zone rules, Next: Authors of parsedatetime, Prev: Seconds since the Epoch, Up: Date input formats\n" }, { "name": "29.10 Specifying time zone rules", "content": "Normally, dates are interpreted using the rules of the current time\nzone, 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, 2004?\" 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\" 2004-10-31 06:30'\nSun Oct 31 01:30:00 EDT 2004\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 '2004-10-31 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 2004, 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'Arctic/Longyearbyen' to 'Antarctica/SouthPole', but if you are at sea\nand have your own private time zone, or if you are using a non-GNU host\nthat does not support the 'tz' database, you may need to use a POSIX\nrule instead. Simple POSIX rules like 'UTC0' specify a time zone\nwithout daylight saving time; other rules can specify simple daylight\nsaving regimes. *Note Specifying the Time Zone with 'TZ': (libc)TZ\nVariable.\n\nFile: coreutils.info, Node: Authors of parsedatetime, Prev: Specifying time zone rules, Up: Date input formats\n" }, { "name": "29.11 Authors of 'parsedatetime'", "content": "'parsedatetime' started life as 'getdate', as originally implemented by\nSteven M. Bellovin () while at the University of\nNorth Carolina at Chapel Hill. The code was later tweaked by a couple\nof people on Usenet, then completely overhauled by Rich $alz\n() and Jim Berets () in August, 1990.\nVarious revisions for the GNU system were made by David MacKenzie, Jim\nMeyering, Paul Eggert and others, including renaming it to 'getdate' to\navoid 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() from the 'parsedatetime.y' source code, and\nthen edited by K. Berry ().\n\nFile: coreutils.info, Node: Examples of date, Prev: Options for date, Up: date invocation\n\n\nHere are a few examples. Also see the documentation for the '-d' option\nin 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\nFri, 09 Sep 2005 13:51:39 -0700\n\n* To convert a date string to the number of seconds since the epoch\n(which is 1970-01-01 00:00:00 UTC), use the '--date' option with\nthe '%s' format. That can be useful in sorting and/or graphing\nand/or comparing data by date. The following command outputs the\nnumber of the seconds since the epoch for the time two minutes\nafter the epoch:\n\ndate --date='1970-01-01 00:02:00 +0000' +%s\n120\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 '946684800' and casually note \"Oh, that's the first\nsecond of the year 2000 in Greenwich, England.\"\n\ndate --date='2000-01-01 UTC' +%s\n946684800\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=2000-01-01 +%s\n946684800\n\nTo convert such an unwieldy number of seconds back to a more\nreadable form, use a command like this:\n\n# local time zone used\ndate -d '1970-01-01 UTC 946684800 seconds' +\"%Y-%m-%d %T %z\"\n1999-12-31 19:00:00 -0500\n\nOr if you do not mind depending on the '@' feature present since\ncoreutils 5.3.0, you could shorten this to:\n\ndate -d @946684800 +\"%F %T %z\"\n1999-12-31 19:00:00 -0500\n\nOften it is better to output UTC-relative date and time:\n\ndate -u -d '1970-01-01 946684800 seconds' +\"%Y-%m-%d %T %z\"\n2000-01-01 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\n2012-06-30 23:59:60 UTC:\n\n# Typical systems ignore leap seconds:\ndate --date='2012-06-30 23:59:59 +0000' +%s\n1341100799\ndate --date='2012-06-30 23:59:60 +0000' +%s\ndate: invalid date '2012-06-30 23:59:60 +0000'\ndate --date='2012-07-01 00:00:00 +0000' +%s\n1341100800\n\n# Atypical systems count leap seconds:\ndate --date='2012-06-30 23:59:59 +0000' +%s\n1341100823\ndate --date='2012-06-30 23:59:60 +0000' +%s\n1341100824\ndate --date='2012-07-01 00:00:00 +0000' +%s\n1341100825\n" } ] } } } }