ROOTVG - AIX & POWER Portal

strange behaviour with "date > test.txt" command

Home

Help

Login

Register

	Welcome, Guest. Please login or register.	September 07, 2010, 01:20:09 AM
		Login with username, password and session length

ROOTVG > AIX > Administration > strange behaviour with "date > test.txt" command

Pages: [1] Go Down

« previous next »

Print

	Author	Topic: strange behaviour with "date > test.txt" command (Read 565 times)
0 Members and 1 Guest are viewing this topic.

fbergenh

Full Member

Posts: 23

Re: strange behaviour with "date > test.txt" command

« Reply #2 on: April 07, 2010, 04:15:26 PM »

Thanks for the answer, John.

The date command was not the problem: the date and time inside the 'test.txt' file was correct.

Only the ls -l inside the directory ( cd /m/dosoe10; ls -l ) returned the wrong modification time on that specific file or any other file created in that directory at that time. ls -l with the complete path ( ls -l /m/dosoe10/test.txt or cd /m/dosoe10; ls -l test.txt ) returned the correct time, and the same test in another directory ( cd /m/dosoe10/client; date > test.txt; ls -l ) was fine too...

I don't want to spend too much time on the issue because everything is fine again, but I am still curious what happened.


	Logged

John R Peck

Administrator
Senior Member

Posts: 129

Re: strange behaviour with "date > test.txt" command

« Reply #1 on: April 03, 2010, 09:03:41 PM »

Sounds like a daylight savings time issue and/or possibly a miss-match with environment settings.

The TZ variable, normally defined in /etc/environment, optionally set elsewhere in say a specific user
.profile file, is the main control over the value of the date/time that is calculated from the base
system clock.

In the past, there have been numerous issues with the TZ automatic smit settings not working
at the correct date. One way to overcome that for the UK, is to use this setting:
TZ=GMT0BST,M3.5.0,M10.5.0

The manual for the "ls" command does not contain anything about TZ, but for the "date" command:
" The following environment variables affect the execution of the date command. LANG Determines the locale to use when both LC_ALL and the corresponding environment variable (beginning with LC_) do not specify a locale. LC_ALL Determines the locale to be used to override any values for locale categories specified by the setting of LANG or any environment variable beginning with LC_. LC_CTYPE Determines the locale for the interpretation of sequences of bytes of text data as characters (for example, single versus multibyte character in an argument). LC_MESSAGES Determines the language in which messages should be written. LC_TIME Determines the contents of date and time strings written by date. NLSPATH Determines the location of message catalogues for the processing of LC_MESSAGES. TZ Specifies the time zone in which the time and date are written, unless the -u option is specified. If the TZ variable is not set and the -u flag is not specified, an unspecified system default time zone is used.
"

So check that your LANG and related settings all match what you think they should be.


	Logged

fbergenh

Full Member

Posts: 23

strange behaviour with "date > test.txt" command

« on: April 01, 2010, 04:16:20 PM »

Last Friday I stumbled upon a strange situation on some of my AIX machines (AIX 53 TL7).

I have the following filesystems:

/m
/m/dosoe10
/m/dosoe10/client

At 14:20, I used the following commando's:
# cd /m/dosoe10
# date > test.txt
# ls -l

When I used the 'ls -l' command, I noticed that the timestamp of the test.txt file was 15:20 Huh

The following command's returned the correct timestamp (14:20) :

# ls -l test.txt (issued from within the same directory)
# ls -l /m/dosoe10/test.txt (issued from within another directory)

When I did the same in some other directories ( for example /m and /m/dosoe10/client ) the strange behaviour did not occur.

Strangely enough, the situation was normal again last monday. I used the same commands again, and the time was shown correctly every time....

Is there someone who can explain this behaviour?