0

According to my understanding, Unix time format is the no of seconds calculated from 1970 00:00:00. For ex, if our current time is 1970 00:01:00, then unix time will be 60 (60 seconds has elapsed from 1970 00:00:00)

If we see this in a syslog below ,

<190>1 1445340430.714226137 BS_S1_MX400 flows src=172.20.62.44 dst=86.162.141.216 mac=00:25:46:20:30:00 protocol=udp sport=16742 dport=15029 pattern: deny udp

1445340430.714226137 - This is the time format

Is the time format is in unix or in some-other format. If this is in unix, then does unix time format includes decimals too?

Improve this question

2 Answers 2

Reset to default
2

"Unix time format" is not a term I'm familiar with; I don't think such a thing exists.

Do you mean "UNIX time"? In that, case, yes, it's the seconds since the beginning of 1970; it's not defined how you store that, and it's not defined that it's only integer fractions. It's just the time that has passed since 1970-01-01 00:00 UTC. The resolution at which things are handled is a different question.

How you print that is yet a completely different question!

So, you'll need to mentally treat three different things:

  1. Time (as in: UNIX time, UTC time, GPS time… ); that's the physics.
  2. Time observation (as in: what resolution does my clock have?); that's the way time is internally handled by your system
  3. Time format (as in: strftime, printing time as full seconds.fractional seconds, or as "Wednesday, shortly after my first afternoon coffee"); that's the way time that was observed/internally handled is displayed.

It's not standardized, and the program you're looking at seems to have decided to print it as a decimal number. OK! The number of digits imply nanosecond resolution, which might make sense, this looks like a message from cellular infrastructure, and these things actually have a notion of nanoseconds. However, that might also imply this isn't UNIX time, but some related time that potentially deals differently with GPS leap second compensation and so on. So, you'll have to read the documentation of your software (or the cellular standard you're using, if my guess is correct).

Improve this answer
2
  • 1
    given that the digit resolv to 2015 (date -d@1445340430) , it is either a very old syslog, or not epoch time.
    – Archemar
    Apr 20, 2022 at 14:57
  • @Archemar good observation. Looking at the actual number again, drawing 18 decimal digits (the leading 1 not counted) and only hitting 0-7 is astonishingly unlikely. As in, practically impossible; even just drawing the 9 fractionally digits has only ~ 4% probability, assuming these are really uniformly distributed (which seems very likely). It really says read the documentation (or source code?) about what this value actually means.
    – Marcus Müller
    Apr 20, 2022 at 15:07
0

What you see is UNIX epoch time. This is number of seconds from 01.01.1970 00:00:00. After the dot you have time in nanoseconds (can be in milliseconds or microseconds) which can be very helpful in some cases (network events timing, database events, etc). The time you mention in human readable form is:

Tuesday, October 20, 2015 11:27:10 AM and 714226137 nanoseconds.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .