New answers tagged

1

Try: eval "`date +'@ s = (86400 - %S) - 60 * (%M + 60 * %H)'`"; echo $s However note that in timezones that have winter and summer time, it won't give the right result if called on the day of the switch from/to summer time, before the switch (which generally happen very early in the morning). Beware that in csh, arithmetic operators are right-...


0

this reads like a homework question. given that you are constrained to only getting hours minutes and seconds you will have to take those numbers and do arithmentic. the arithmetic is not complex, I'm sure you can work it out. this will not give a reliable result because there is a race condition if the minute changes during the determination of those ...


3

Assuming you have GNU date (or another date program that understands -d and works properly) and using bash: You can use the -d flag to report time at various points. So, for example % date -d "00:00:00 tomorrow" Sat Jul 16 00:00:00 EDT 2016 We can use this to report on seconds with +%s % date -d "00:00:00 tomorrow" +%s 1468641600 We know our current ...


3

Ryan's post does provide an interesting idea, however, it fails in several regards. While testing with tail -f /var/log/syslog | xargs -L 1 echo $(date +'[%Y-%m-%d %H:%M:%S]') $1 , I noticed that timestamp stays the same even if stdout comes later with difference in seconds apart. Consider this output: [2016-07-14 01:44:25] Jul 14 01:44:32 eagle dhclient[...


1

You can do this with date and xargs: ... | xargs -L 1 echo `date +'[%Y-%m-%d %H:%M:%S]'` $1 Explanation: xargs -L 1 tells xargs to run the proceeding command for every 1 line of input, and it passes in the first line as it does so. echo `date +'[%Y-%m-%d %H:%M:%S]'` $1 basically echoes the date with the input argument at the end of it


0

UNIX time is measured on your computer, running UNIX. This answer is going to expect you to know what Coördinated Universal Time (UTC), International Atomic Time (TAI), and the SI second are. Explaining them is well beyond the scope of Unix and Linux Stack Exchange. This is not the Physics or Astronomy Stack Exchanges. The hardware Your computer ...


25

Your headline question doesn't have a real answer; Unix time isn't a real timescale, and isn't "measured" anywhere. It's a representation of UTC, albeit a poor one because there are moments in UTC that it can't represent. Unix time insists on there being 86,400 seconds in every day, but UTC deviates from that due to leap seconds. As to your broader question,...


11

The adjustments to the clock are co-ordinated by the IERS. They schedule the insertion of a leap second into the time stream as required. From The NTP Timescale and Leap Seconds The International Earth Rotation Service (IERS) at the Paris Observatory uses astronomical observations provided by USNO and other observatories to determine the UT1 (navigator'...


0

As others have explained, it is in the nature of log files that one does not get out of order entries, no matter what happens to timestamps. The problem that you are envisaging is ambiguity, where a poorly chosen timestamp mechanism does not uniquely denote a single point in time. This makes it hard for the poor system administrator reading logs to ...


2

Yes, rsync is your best bet. Something like this should work: rsync -vr --size-only --times <source> <dest> --size-only tells rsync not to copy the files again, --times tells it to update timestamps.


0

There are simpler ways to do this if one can assume that no file names has white space or newlines in its name. In the modern world, one cannot assume this and, besides, it is bad form to write scripts so fragile that they fail if such a legal file name is found. To be safe, use the following (GNU tools may be required): find ../ini/ -type f -printf '%T@ %...


0

Log files can use a time format such as ISO 8601 or its cousin RFC 3339 that shows local time as an adjustment of UTC. If the time entries end with Z or if it ends in a hyphen (8601), minus or plus followed by an offset value then it's using a format based on UTC. When the log is based on UTC then daylight shows up as a change in the offset. The offset ...


2

Logfiles do not "handle" time zones, they just record what some application or service wrote there. So if an application writes "just the messages" and "directly to the log file", you're out of luck. Some syslog servers (like syslog-ng) allow you to "decorate" the "raw" log data by time stamps, where you can choose to use UTC or local time with or without ...


6

Logfiles are plain text files, and each line is appended at the end. So there is no loss of data when using non-UTC timezone. Of course, you may view the files using a tool which can get confused. However, the usual reason for using UTC is to avoid ambiguity: you do not have to know what the local timezone is to interpret the data. So yes, using UTC in ...



Top 50 recent answers are included