#1 楼
date +%s
将返回自该纪元以来的秒数。
此：
date +%s%N
将返回秒数和当前的纳秒数。
So：
date +%s%N | cut -b1-13
将为您提供自该纪元以来的毫秒数-当前秒数加上左三分之一纳秒。 ）
#2 楼
您可以简单地使用%3N将纳秒截断为3个最高有效数字（然后是毫秒）：$ date +%s%3N
1397392146866
在我的Kubuntu 12.04（精确的穿山甲）上。
但是请注意，根据目标系统的不同，可能无法实现
%N。例如。在嵌入式系统（buildroot rootfs，使用非HF ARM交叉工具链编译）上进行了测试，没有%N：$ date +%s%3N
1397392146%3N
（还有我的（非根）Android平板电脑没有
%N。）评论
@warren：我看到您编辑了1397392146％3N并将其更改为1397392146％N，但是1397392146％3N的输出是我在android平板电脑的busybox控制台上真正看到的。您能解释一下您的编辑吗？
–乔
15年6月25日在8:00
沃伦（Warren）的评论是“从3更改为6，因为3仅会使您达到微秒”。他的编辑似乎完全是虚假的。你应该回滚。
–布克佐尔
2015年12月25日，0：27
这是GNU coreutils特别的功能。最终，这是在gnulib中实现的：github.com/gagern/gnulib/blob/…。
–菱角菌属
17年11月6日在20:23
可能那里的一个点很有意义。 date +％s。％3N打印1510718281.134。
– Darksky
17年11月15日下午4:01
这应该是公认的答案。
–诺亚·萨斯曼（Noah Sussman）
19年4月30日在15:29
#3 楼
date +%N在OS X上不起作用，但是您可以使用以下之一：Ruby：ruby -e 'puts Time.now.to_f' Python：
python -c 'import time; print time.time()' Node.js：
node -e 'console.log(Date.now())' PHP：
php -r 'echo microtime(TRUE);' 长生不老药：
DateTime.utc_now() |> DateTime.to_unix(:millisecond) 互联网：
wget -qO- http://www.timeapi.org/utc/now?\s.\N 或以毫秒为单位四舍五入到最接近的秒
date +%s000 评论
为了完整性... node -e'console.log（Date.now（））'
–slf
13年10月10日在18:06
使用PHP：php -r'echo microtime（TRUE）;'
– TachyonVortex
13年11月22日在16:41
当然，您只需要等待这些口译员热身即可。这也可行：wget -qO- http://www.timeapi.org/utc/now?\\s.\\N
–卡米洛·马丁（Camilo Martin）
2014年6月23日下午13:26
或者，如果您实际上不需要毫秒，而只需正确的格式：date +％s000
–Lenar Hoyt
15年4月22日在16:15
apple.stackexchange.com/questions/135742/…具有通过Brew的coreutils在OSX中进行此操作的说明
–相同
17年11月17日在19:53
#4 楼
我的解决方案不是最好的，但是它对我有用：#5 楼
只是把它扔在那里，但我认为带除法的正确公式是：echo $(($(date +%s%N)/1000000))
#6 楼
此解决方案可在macOS上使用。如果您考虑使用Bash脚本并提供Python，则可以使用以下代码：
#!/bin/bash
python -c 'from time import time; print int(round(time() * 1000))'
#7 楼
对于建议运行外部程序以这样的速度获取毫秒数的人们，您也可以这样做：从这里开始，请记住，并非所有程序都会在一秒钟内运行。衡量！
评论
您不需要询问本地系统的时间。我想这暗示了这个问题。您还依赖于网络连接。
–orkoden
15年1月29日在11:27
@orkoden该问题明确询问“自1970年1月Unix时代以来的毫秒数”。另外，我更要指出的是，您不应该仅仅为了获得时间而启动整个Ruby或Python（或wget）-是通过快速通道完成还是以毫秒为单位。
–卡米洛·马丁（Camilo Martin）
15年1月29日在11:57
是的，我知道您给出的解决方案更糟，以突出不良解决方案的缺陷。我尝试了几种解决方案并测量了时间。 lpaste.net/119499结果有点有趣。即使在非常快的i7机器上，日期也需要3毫秒才能运行。
–orkoden
15年1月29日在12:38
@orkoden不错的测试！什么操作系统？这可能与进程产生的开销有关。
–卡米洛·马丁（Camilo Martin）
15年1月30日在13:18
@Nakilon，这就是为什么不应该像任何东西那样依赖可卷曲的便利。
–卡米洛·马丁（Camilo Martin）
17年5月17日在22:24
#8 楼
如果您正在寻找一种显示脚本运行时间的方法，则以下内容将提供（并非完全准确）的结果：尽可能在脚本的开头，输入following
basetime=$(date +%s%N) 这将为您提供类似于1361802943996000000的起始值。
在脚本结尾处，使用以下内容
echo "runtime: $(echo "scale=3;($(date +%s%N) - ${basetime})/(1*10^09)" | bc) seconds" 将显示类似
runtime: 12.383 seconds 注意：
（1 * 10 ^ 09）可以用1000000000替换。
"scale=3"是一种相当罕见的设置，强制bc执行您想要的操作。还有更多！我只在Windows 7 / MinGW上进行了测试...我手边没有合适的* nix框。
评论
或者您可以只使用时间
评论
我不知道削减增加了多少毫秒:-)
–凯尔·勃兰特（Kyle Brandt）
2010年6月14日在16:23
或者，如果您想在Shell中完成所有操作，则避免了额外过程的昂贵开销（实际上，当％+ s + N中的位数发生变化时，我们可以避免此问题）：echo $（（$（date +％s％N）/ 1000））
– MikeyB
2010-6-14在16:38
我认为值得注意的是，该人要求使用Unix，而不是Linux，并且当前的最高答案（日期+％s％N）在我的AIX系统上不起作用。
– Pete
2011年10月25日在16:52
@Pete +1与OS X和FreeBSD相同
– ocodo
2012年5月19日，0：28
％N在OSX Yosemite上不起作用
–马特·克拉克（Matt Clark）
15年6月3日在20:32