this option stands for identifying delimiter and here its dot
-k3.1,3.4n
"k start,stop" stands for field to start and stop at...first am sorting on years which happens to be 3rd column..so 3.1 means third column first character until fourth character..
same applies for all the other "k" options...where second is for sorting on months and then sorting on days...
Note that if you want to sort by date and time, with the data you have the following sort command will work:
sort -k1.7,1 -k1.4,1.5 -k1.1,1.2 -k2,2 input
Note that this sort uses the default whitespace field delimiter, instead of a period because the time stamps aren't delimited by a period. Note also that since your data has fixed-wdith date and time fields with leading zeros, you can use either an alphanumeric sort or a numeric sort for the date fields. Using an alphanumeric sort for the time stamp allows us to use one key -k2,2 instead of three keys -k2.1,2.2 -k2.4,2.5 -k2.7,2.8 to sort the time. (A numeric sort -k2n,2 would only sort on the hour since ":" is not a numeric character.)
The sort keys (in order) are from the 7th character in the 1st field to the end of the 1st field (year), from the 4th character through the 5th character in the 1st field (month), from the 1st character through the 2nd character in the 1st field (day), and from the start of the 2nd field to the end of the 2nd field (time).
Since your sample input data only had one time stamp per day, I tested the above command using the following input (which duplicates the input you provided but changes the date stamps on the 2nd occurrence of each entry to verify that differences in hours, minutes, and seconds all sort correctly:
I guess I don't know what you mean by "more robust".
The sort utility is available on any UNIX system and on any Linux system; the dconv utility is not available on many of those systems. (For example, dconv is not available on OS X.)
The sort command I provided will work for any dates from year 0001 through 9999 as long as all of the dates are in this format. I don't have access to dconv, but I'm guessing that if you add the line:
to your input file, you'll find that it ends up last on the output rather than first.
(And, yes I know that fixing it for this example only involves adding 3 characters to your command line. :rolleyes: ) However, if you happen to be using a programming environment with a 32-bit time_t, your date range is much more limited.
I mean that dconv is actually made to parse and operate on dates, sort is not.
True.
You guessed wrong. And I'm curious as to what 3 characters you meant? Also, dconv doesn't depend on time_t at all, so it will work exactly the same on 16-bit, 32-bit and 64-bit systems (all tested).
dconv -S -i '%d.%m.%Y %T' <<EOF | sort | dconv -f '%d.%m.%Y %T' -S
22.06.2012 17:58:38 CPUser: xxxxxxx, billedAfterStatus: Active
13.07.2012 08:46:15 CPUser: xxxxxxx, billedAfterStatus: Active
20.07.2012 08:56:24 CPUser: xxxxxxx, billedAfterStatus: Active
20.03.2012 08:56:24 CPUser: xxxxxxx, billedAfterStatus: Active
20.05.2012 08:56:24 CPUser: xxxxxxx, billedAfterStatus: Active
20.07.2000 08:56:24 CPUser: xxxxxxx, billedAfterStatus: Historical
EOF
=>
20.07.2000 08:56:24 CPUser: xxxxxxx, billedAfterStatus: Historical
20.03.2012 08:56:24 CPUser: xxxxxxx, billedAfterStatus: Active
20.05.2012 08:56:24 CPUser: xxxxxxx, billedAfterStatus: Active
22.06.2012 17:58:38 CPUser: xxxxxxx, billedAfterStatus: Active
13.07.2012 08:46:15 CPUser: xxxxxxx, billedAfterStatus: Active
20.07.2012 08:56:24 CPUser: xxxxxxx, billedAfterStatus: Active
OK. I'll take your word for it. My system doesn't have dconv and there are no dconv man pages in the sets of man pages provided here on unix.com.
Without access to a dconv man page I (apparently incorrectly) assumed that dconv -S -i '%d.%m.%Y %T' used the strptime() format string argument to convert the text date string into a seconds since the Epoch value, sort sorted the seconds since the Epoch values, and dconv -f '%d.%m.%Y %T' -S converted seconds since the Epoch back to the original text string format using an strftme() date format string. Since the number of seconds since the Epoch in 2012 is represented as a ten digit decimal string in the range 1325xxxxxx-1357xxxxxx and the number of seconds since the Epoch in 2000 was a nine digit string in the range 946xxxxxx-978xxxxxx, I expected the alphanumeric sort specified by sort to sort "9" after "1". If my assumption had been correct, it could have been fixed by telling sort to do a numeric sort sort -n instead of an alphanumeric sort sort .
Ah I see. No, what happens is dconv with no output format specifiers will return ISO 8601 dates (aka 2012-10-31T17:44:00) which are sortable just like that, UNLESS of course you go before the year 1000 or after the year 9999, but ISO isn't defined for those dates anyway :).
OK. Thanks. Yes, the ISO 8601 format for a complete representation of the local date and time can be sorted as a single alphanumeric field using a single (default) key in sort.
So with the input file format being discussed in this thread, the commands:
Assuming that all of the year values being sorted have the same value for the first two digits (assuming that the YY is the last two digits of a four digit year) and that there are always the same number of spaces between YY and HH , you could either use: