this is appended automatically in my url. I know about the first part. i.e 1515663000. which denotes the unix timestamp of 11/01/2018 9:30AM. what about the second one i.e. after the period. (7121028900146484375000)

closed as unclear what you're asking by Jeff Schaller, Rui F Ribeiro, mdpc, jimmij, Timothy Martin Jan 12 '18 at 17:53

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


This is a Wordpress function which uses a timestamp in seconds and microseconds, cast to 22 decimal places. See this code reference for the detail.

Empirically it seems that casting a timestamp to 22 digits adds pseudo-random junk to the least significant part:

x=$(date +%s.%N)    # %N is nanoseconds, 9 digits. Microseconds would be
                    # 6 digits but the principle is similar enough

printf "%s -- %.22F\n" "$x" "$x"
1515706488.768975900 -- 1515706488.7689759000204503536224

As an aside, the human-readable date "11/01/2018" as written in your question is ambiguous. In some parts of the world it reads as you (and I) would consider "01/11/2018". Furthermore the time part (and actually, potentially the date too) will vary depending on your time zone. For that reason it would be better to describe 1515663000 as being equivalent to "11 Jan 2018 09:30:00 UTC".

  • The 0.7121028900146484375000 part has 22 decimal places, while a nano-second only has 9 places. OTOH, the 146484375 portion might be an embedded date from 2016. – D McKeon Jan 11 '18 at 21:03
  • @DMcKeon good catch. Answer amended – roaima Jan 11 '18 at 21:38
  • Even more locale independent would be using the ISO 8601 format (perhaps using spaces for readability), with the additional advantage that it is alphabetically sortable: 2018-01-11 09:30:00 +00:00 – Murphy Jan 12 '18 at 10:14
  • @Murphy programmatically I almost always use YYYY-MM-DD and HH:mm:ss (UTC) for my dates and times. These avoid language/locale issues. For "conversational" dates with people outside my country I tend to use their timezone (and reference as "your time"), but never an unqualified 1/2/2018 format date. – roaima Jan 12 '18 at 10:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.