Tag Info

Hot answers tagged

66

This is a matter of portability. In early Unices, some versions of cron accepted 0 as Sunday, and some accepted 7 as Sunday -- this format is an attempt to be portable with both. From man 5 crontab in vixie-cron (emphasis my own): When specifying day of week, both day 0 and day 7 will be considered Sunday. BSD and AT&T seem to disagree about ...


34

On *BSD: date -r 1234567890 On Linux (specifically, with GNU coreutils ≥5.3: date -d @1234567890 With older versions of GNU date: date -d '70-1-1 + 1234567890 sec' If you need portability, you're out of luck. The only time you can format with a POSIX shell command (without doing the calculation yourself) line is the current time. In practice, Perl ...


27

You should be able to set a timezone for the duration of the query, thusly: TZ=America/New_York date Note the whitespace between the TZ setting and the date command. This sets the TZ variable only for the command line.


25

Sometimes you don't even need the source code. Use strace. $ strace touch -t 201212121212 foobar execve("/usr/bin/touch", ["touch", "-t", "201212121212", "foobar"], [/* 61 vars */]) = 0 [...] lots of noise [...] open("foobar", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3 dup2(3, 0) = 0 close(3) ...


23

In addition to @ChrisDown's excellent answer, this might also be a nifty solution to a localisation issue: "According to the Hebrew calendars and traditional Christian calendars, Sunday is the first day of the week." Having it both ways, which is really easy programmatically, makes it easy to use for either group.


22

This depends on exactly what you mean by "opened", but in general, yes. There are three timestamps normally recorded: mtime — updated when the file contents change. This is the "default" file time in most cases. ctime — updated when the file or its metadata (owner, permissions) change atime — updated when the file is read So, generally, what you want to ...


21

The "n weeks after a date" is easy with GNU date(1): $ date -d 'now + 3 weeks' Tue Dec 6 23:58:04 EST 2011 $ date -d 'Aug 4 + 3 weeks' Thu Aug 25 00:00:00 EST 2011 $ date -d 'Jan 1 1982 + 11 weeks' Fri Mar 19 00:00:00 EST 1982 I don't know of a simple way to calculate the difference between two dates, but you can wrap a little logic around date(1) with a ...


19

touch calls the utimes system call to set the file's modification time and its access time. On some systems, instead of utimes, it opens the file and then sets the file times through the descriptor, e.g. with utimensat under Linux. You can see how touch works on your system by looking at the system calls it makes. Under Linux, use strace, e.g. strace touch ...


16

I have encountered this problem in an embedded Linux system that needed to handle dates past 2038 in some long-term cryptographic certificates, so I'd say the likehood of this depends on your application domain. While most systems should be ready well before 2038, if you find yourself today calculating dates far into the future, you may have a problem.


15

You want the find tool. find folder -depth -type f -atime +7 -delete (This will delete all files (only regular ones, no pipes, special devices, directories, symbolic links) in the given folder and all subdirectories (recursively) where the last access time is longer than 7 days ago.)


13

date -d @1190000000 Replace 1190000000 with your epoch


13

My shortest method uses zsh: print -rl **/*(.Om) If you have GNU find, make it print the file modification times and sort by that. I assume there are no newlines in file names. find . -type f -printf '%T@ %p\n' | sort -k 1 -n | sed 's/^[^ ]* //' If you have Perl (again, assuming no newlines in file names): find . -type f -print | perl -l -ne ' ...


13

Using the libfaketime software could be a solution sudo apt-get install faketime faketime '2006-09-20' wine Example.exe


12

I think this is going to be a significant problem, much more pernicious than the Y2K issues of 1999/2000 because the affected code is generally lower-level (it's CTIME) and so it's harder to spot places where time is being stored that way. To complicate matters further, the fact that Y2K was perceived to be a damp squib will make it harder to draw attention ...


12

Good question. The documentation says it should be allowed. info date 'Date input formats' 'Calendar date items' For numeric months, the ISO 8601 format `YEAR-MONTH-DAY' is allowed, where YEAR is any positive number, ... A leading zero must be present if a number is less than ten. If YEAR is 68 or smaller, then 2000 is added to it; ...


12

Try running this code snippet: if [[ 5 < 20 ]] then echo "5 < 20, as expected" else echo "5 is not less than 20, but why?" fi And the output would be 5 is not less than 20, but why?. The answer is that you're using the < conditional expression operator, which is documented as doing: string1 < string2 True if ...


11

You could use some evil trickery: date -d "Feb 12 10:02:10" +%s will return the number of seconds since the epoch for that date. Combining this with the same command (for the other date) and running through bc: echo "`date -d 'Feb 12 10:53:15' +%s` - `date -d 'Feb 12 10:02:10' +%s`" | bc Will give you 3065 the number of seconds between the times. ...


11

A python example for calculating the number of days I've walked the planet: $ python >>> from datetime import date as D >>> print (D.today() - D(1980, 6, 14)).days 11476


11

In your case, you can simply disable zero padding by append - after % in the format string of date: %-H By default, date pads numeric fields with zeroes. The following optional flags may follow '%': - (hyphen) do not pad the field _ (underscore) pad with spaces 0 (zero) pad with zeros ^ use upper case if possible # use opposite case if ...


10

You can get the current unix timestamp with date "+%s", find the current quarter-hour with some simple math (my example is in bash) and print it back with a better format with date : curdate=`date "+%s"` curquarter=$(($curdate - ($curdate % (15 * 60)))) date -d"@$curquarter" The @ syntax to set the current date and time from a timestamp is a GNU extention ...


10

I was going to suggest hacking e2fsck to disable the specific checks for a last mount time or last write times in the future. These are defined in problem.c / problem.h, and used in super.c. But in looking, I discovered that E2fsprogs 1.41.10 adds a new option to /etc/e2fsck.conf called broken_system_clock. This seems to be exactly what you need, and since ...


10

One solution is: find -type f -mtime 90 That finds files that was last modified exactly 90 days ago. find -type f -mtime -90 finds files that were modified in last 90 days.


10

You can use man ls and here you can find --time-style parameter. Or you can use: ls --full-time.


10

I think it's taking your + x as a time-zone specifier (e.g., consider 2013-04-25 19:52:36 +4 is a valid timestamp, in in a time zone 4 hours ahead of UTC). It's then seeing the word 'minutes', and treating it as a synonym of minute, so giving you one minute later. If you put in an explicit timezone specifier, it works: anthony@Zia:~$ TZ=utc date -d ...


10

The reason is that TZ=UTC-8 is interpreted as a POSIX time zone. In the POSIX timezone format, the 3 letters are the timezone abbreviation (which is arbitrary) and the number is the number of hours the timezone is behind UTC. So UTC-8 means a timezone abbreviated "UTC" that is −8 hours behind the real UTC, or UTC + 8 hours. (It works that way ...


10

The Unix time is given as seconds since the epoch, the number of seconds that has passed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds. The GNU date command has some very nice features that allow you to translate between different time formats. These are explained very nicely in man date so I will only ...


9

Unfortunately, none of the POSIX command line utilities provide arithmetic on dates. date -d and date +%s are the way to go if you have them, but they're GNU extensions. There's a clumsy hack with touch that sort of works for checking that a date is at least n days in the past: touch -t 201009090000 stamp if [ -n "$(find stamp -mtime +42)" ]; then ... ...


9

A 64 bit OS is ultimately irrelevant to the 2037 problem. (CTIME runs out closer to 2037 than 2038). The question is not the bit depth of the OS, rather how does the OS store time. Or how does the database column choose to store time. Or how does this directory services time syntax attribute store time at the back end. This is a much bigger problem ...


9

You can do this by manipulating the TZ environment variable. The following will give you the local time for US/Eastern, which will also be smart enough to handle DST when that rolls around: # all on one line TZ=":US/Eastern" date +%Y%m%d The zone name comes from the files and directories inside /usr/share/zoneinfo.


9

Files managed by your package management are put there by extracting these packages. Effectively, these packages are just archives (cpio format for RPM, ar for DEBs). By extracting these files, the modification date is preserved, just as would happen when you create a ZIP file and extract them on a later time. The date you're seeing is the time the packages ...



Only top voted, non community-wiki answers of a minimum length are eligible