72

I have been developing a script on my linux box for quite some time, and wanted to run it on my Mac as well.

I thought that the functions on the Mac were the same as the functions on linux, but today I realized it was wrong. I knew that fewer functions existed on the Mac, but I thought that the functions that did exist, had the same implementation.

This problem is specifically in regards to the date command.

When I run the command on my linux machine with the parameter to provide some time in nanoseconds, I get the correct result, but when I run it on my mac, it does not have that option.

Linux-Machine> date +%N
55555555555 #Current time in nanoseconds
Mac-Machine> date +%N
N

How do I go about getting the current time in nanoseconds as a bash command on the Mac?

Worst case is I create a small piece of code that calls a system function in C or something and then call it within my script.

Any help is much appreciated!

Kaushik Shankar
  • 5,491
  • 4
  • 30
  • 36
  • The worst one is sed ;-) – callumacrae Mar 21 '12 at 12:53
  • 3
    I would not rely on Linux regarding compliance to some Unix standard. Mac OS X follows Single Unix Specification V3, not Linux. Moreover a date with a nanosecond precision obtained from a bash command is very precise but not that much accurate. What is your need? – mouviciel Mar 21 '12 at 13:02
  • Thanks for your input guys. I will learn about GNU vs. BSD, and check out the differences between sed. @mouviciel, I wanted to create a custom `time` command. – Kaushik Shankar Mar 22 '12 at 22:52
  • 1
    FWIW, zsh with `zmodload zsh/datetime` gives you the variable `$EPOCHREALTIME` as a floating point epoch timestamp. Of course it doesn't help you much if you don't use zsh, but generally speaking, forking a process to obtain a precise time value (by using `date`) is just questionable. Yes, it may be slightly superior by "guaranteeing" a unique timestamp (compared to just fetching the epoch seconds) but that's about it – Steven Lu Apr 26 '16 at 13:19

3 Answers3

106

This is because OSX and Linux use two different sets of tools. Linux uses the GNU version of the date command (hence, GNU/Linux). Remember that Linux is Linux and OS X is Unix. They're different.

You can install the GNU date command which is included in the "coreutils" package from MacPorts. It will be installed on your system as gdate. You can either use that, or link the date binary with the new gdate binary; your choice.

JoeLinux
  • 4,198
  • 1
  • 29
  • 31
  • 49
    It's worth noting that coreutils is in [Homebrew](http://mxcl.github.io/homebrew/) as well which makes installation a snap. Just install Homebrew and then `brew install coreutils` and you've got gdate. – Nick Jul 07 '13 at 02:19
  • 4
    I know this is more than 2 yrs old, but thanks! I had a very complex date formatting snippet in a script used in a large-scale database project that made use of `date`'s excellent `-d` flag. Glad to be able to still use it on Mac. – Jangari Sep 19 '14 at 03:45
  • `gdate +%H:%M:%S.%3N` will print current time with milliseconds – kjian Mar 31 '21 at 08:51
  • `alias date=gdate` – Abhishek Gupta May 09 '23 at 07:49
9

man date indicates that it doesn't go beyond one second. I would recommend trying another language (Python 2):

$ python -c 'import time; print repr(time.time())'
1332334298.898616

For Python 3, use:

$ python -c 'import time; print(repr(time.time()))'
u32i64
  • 2,384
  • 3
  • 22
  • 36
callumacrae
  • 8,185
  • 8
  • 32
  • 49
  • 30
    I always spin up a Python interpreter when I need to know what nanosecond it is _right now_. ;-) – Josh Lee Mar 21 '12 at 12:53
  • 1
    haha, fair point - but can you think of any better solutions? – callumacrae Mar 21 '12 at 12:55
  • Thanks for the answer @Callum Macrae, but I think I'll have to go with the other answer because it will give me more accurate results. – Kaushik Shankar Mar 23 '12 at 16:26
  • Fair enough. I didn't know that you weren't distributing the script though, in which case you wouldn't be able to use gdate. – callumacrae Mar 23 '12 at 20:34
  • Installing coreutils gives you more flexibility than just printing the nanoseconds; e.g. the powerful `--date=` option of GNU `date`. – musiphil Feb 03 '16 at 07:54
  • Why do you think GNU `date` will give you more accurate results? It will probably be quicker than all of Python to execute but the overhead will probably still completely dominate over any accuracy improvement. – tripleee Feb 27 '18 at 05:55
6

There are "Linux specifications" but they do not regulate the behavior of the date command much. What you have is really the opposite -- Linux (or more specifically the GNU user-space tools) has a large number of extensions which are not compatible with Unix by any reasonable definition.

There is a large number of standards which do regulate these things. The one you should be looking at is POSIX which requires

date [-u] [+format]

and nothing more to be supported by adhering implementations. (There are other standards like XPG and SUS which you might want to look at as well, but at the very least, you should require and expect POSIX these days ... finally.)

The POSIX document contains a number of examples but there is nothing for date conversion which is however a practical problem which many scripts turn to date for. Also, for your concrete problem, there is nothing for reporting times with sub-second accuracy in POSIX.

Anyway, griping that *BSD isn't Linux isn't really helpful here; you just have to understand what the differences are, and code defensively. If your requirements are complex or unusual, perhaps turn to a scripting language like Perl or Python which perform these types of date formatting operations more or less out of the box in a standard installation (though neither Perl nor Python have a quick and elegant way to do date conversion out of the box, either; solutions tend to be somewhat tortured).

In practical terms, you can compare the MacOS date man page and the Linux one and try to reconcile your requirements.

For your practical requirement, MacOS date does not support any format string with nanosecond accuracy, but nor are you likely to receive useful results on that scale when the execution of the command will take a significant number of nanoseconds. I would settle for millisecond-level accuracy (and even that is going to be thrown off by the execution time in the final digits) and multiply to get the number in nanosecond scale.

nanoseconds () {
      python -c 'import time; print(int(time.time()*1000*1000*1000))'
}

(Notice the parentheses around the argument to print() for Python 3.) You will notice that Python does report a value at nanosecond accuracy (the last digits are often not zeros), though by the time you have run time.time() the value will obviously no longer be correct.

To get an idea of the error rate,

bash@macos-high-sierra$ python3
Python 3.5.1 (default, Dec 26 2015, 18:08:53)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> import timeit
>>> def nanoseconds ():
...   return int(time.time()*1000*1000*1000)
...
>>> timeit.timeit(nanoseconds, number=10000)
0.0066173350023746025
>>> timeit.timeit('int(time.time()*1000*1000*1000)', number=10000)
0.00557799199668807

The overhead of starting Python and printing the value is probably going to add a few orders of magnitude of overhead, realistically, but I haven't attempted to quantify that. (The output from timeit is in seconds.)

tripleee
  • 175,061
  • 34
  • 275
  • 318