Hi nezabudka,
Note that although the above code will work in many cases, there are a few issues that will cause it to fail intermittently:
First, the command in the command substitution:

Code:

LANG=C date -d -30minutes -u +"%Y%m%d%T"

You may have noticed that when I used a similar construct in the code I suggested in post #9 (correctly in all the ksh93 printf calls and sometimes correctly in the GNU date invocations [all have now been fixed]) that I used LC_ALL=C instead of LANG=C. These environment variables (along with other LC_* variables for the various locale categories have a hierarchy that determines which variable controls the operation when more than one of them are found in the environment. For example, if I run the command RudiC mentioned in post #11 to get a locale's abbreviated month names with the three variables that control the strings used to define a locale's month names all set to different values: LC_ALL=ru_RU specifying a Russian locale for all locale categories no matter what other locale variables are set, LC_TIME=it_IT specifying an Italian locale for time related strings defined by the standards, and LANG=C specifying the locale to be used if none of the other locale environment variables are set, we see that if LC_ALL is defined on the command line (or in your environment) it overrides all of the other locale variables:

Code:

LC_ALL=ru_RU LC_TIME=it_IT LANG=C locale abmon
янв;фев;мар;апр;май;июн;июл;авг;сен;окт;ноя;дек

which gives us the abbreviated month names in Russian. If we drop the setting for LC_ALL (and don't have LC_ALL set in the environment), the command:

Code:

LC_TIME=it_IT LANG=C locale abmon
Gen;Feb;Mar;Apr;Mag;Giu;Lug;Ago;Set;Ott;Nov;Dic

which gives us Italian abbreviated month names. So, if you want to want to guarantee that the date utility will English names for things like "minutes" and "seconds" when using date -d time_base or date --date time_base, you need to use LC_ALL=C or LC_ALL=POSIX instead of LANG=C or LANG=POSIX. Note that I don't have a GNU date utility installed on my system and I don't know which locale category it uses to match the time period strings in -d option-arguments. I would guess that they are controlled by LC_TIME, but they could also be controlled by LC_MESSAGES. Either way, setting LC_ALL will override it and give you what you want.

Second, in the awk statement:

Code:

split($5, a, ":" s)

you only get the results you want because the variable s is not defined in your script. To reduce confusion and protect against a user invoking your awk script with a defined s variable, change the last argument in that function call to just ":" instead of ":" s.

Third, the expression in the awk if statement:

Code:

if ($5 == 24) $5 = "00"

can't ever yield a true result. In this script, $5 on the lines you're processing will always be of the form hh:mm:ss,sss where hh is the hour in 12-hour clock format (01-12), mm is the minute (00-59), and ss,sss is the seconds (00-60) and subseconds apparently consisting of 1 to 3 decimal digits representing tenths, hundredths, or thousandths of a second. There is no way that a string representing a clock for the current time in the above form will ever be the string 24, nor even start with that string. Presumably you want to determine if the hour portion of the time field is 12 and, if it is, reset it to 00 (which will be the correct 24-hour clock hour field if the AM/PM indicator is AM and will later be incremented back to 12 if the AM/PM indicator is PM. I would guess that you would get what you had intended to do if you change the two lines in your code:

Code:

        if ($5 == 24) $5 = "00"
        if ($7 == "PM") $5 = (a[1]+=12) ":" a[2] ":" a[3]

to:

Code:

        if (a[1] == 12) $5 = (a[1] = "00") ":" a[2] ":" a[3]
        if ($7 == "PM") $5 = (a[1]+=12) ":" a[2] ":" a[3]

or to:

Code:

        if (a[1] == 12 && $7 == "AM") $5 = "00:" a[2] ":" a[3]
        if (a[1] < 12 && $7 == "PM") $5 = (a[1] + 12) ":" a[2] ":" a[3]

If you run into issues similar to these in the future, I hope these comments will help you understand some of the pitfalls you have to watch out for when writing code to deal with various date and time formats.

Cheers,
Don