Wireless Access

Reply
Regular Contributor I
Posts: 190
Registered: ‎04-27-2009

Change from 12am/pm to 24hour format , germany

hi there,

 

in "process logs" i see proper time-zone/and the correct time , in the dashboard it shows a different timezone like this :

 

http://i.snag.gy/FLvVN.jpg

 

http://i.snag.gy/kX5qy.jpg

 

how to change also in AirWave AWMS the 24hour format so we dont have to calculate the time-format .

 

i.snag.gy/f54Wr.jpg

 

ISO8601 i think is the key...

 

regards

benjamin

Moderator
Posts: 1,252
Registered: ‎10-16-2008

Re: Change from 12am/pm to 24hour format , germany

On the AMP side, it's a feature request to submit via Ideas Portal.  Things to double check: System -> Performance -> Current Time, and then Group -> Basic -> Timezone.  As you may place different devices in different groups based on timezone.


Rob Gin
Senior QA Engineer - Network Services
Aruba Networks, a Hewlett Packard Enterprise Company
Regular Contributor I
Posts: 190
Registered: ‎04-27-2009

Re: Change from 12am/pm to 24hour format , germany

Hi ,

 

>>System -> Performance -> Current Time

shows pacific time America/Los_Angeles

 

the timezone set in basic is Europe/Berlin

 

I googled , and found that "tzselect" should work i tried to set :

 

[quote]

[root@localhost mercury]# tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent or ocean.
 1) Africa
 2) Americas
 3) Antarctica
 4) Arctic Ocean
 5) Asia
 6) Atlantic Ocean
 7) Australia
 8) Europe
 9) Indian Ocean
10) Pacific Ocean
11) none - I want to specify the time zone using the Posix TZ format.
#? 8
Please select a country.
 1) Aaland Islands        18) Greece                35) Norway
 2) Albania               19) Guernsey              36) Poland
 3) Andorra               20) Hungary               37) Portugal
 4) Austria               21) Ireland               38) Romania
 5) Belarus               22) Isle of Man           39) Russia
 6) Belgium               23) Italy                 40) San Marino
 7) Bosnia & Herzegovina  24) Jersey                41) Serbia
 8) Britain (UK)          25) Latvia                42) Slovakia
 9) Bulgaria              26) Liechtenstein         43) Slovenia
10) Croatia               27) Lithuania             44) Spain
11) Czech Republic        28) Luxembourg            45) Sweden
12) Denmark               29) Macedonia             46) Switzerland
13) Estonia               30) Malta                 47) Turkey
14) Finland               31) Moldova               48) Ukraine
15) France                32) Monaco                49) Vatican City
16) Germany               33) Montenegro
17) Gibraltar             34) Netherlands
#? 16

The following information has been given:

        Germany

Therefore TZ='Europe/Berlin' will be used.
Local time is now:      Wed Dec  4 09:53:08 CET 2013.
Universal Time is now:  Wed Dec  4 08:53:08 UTC 2013.
Is the above information OK?
1) Yes
2) No
#? 1

You can make this change permanent for yourself by appending the line
        TZ='Europe/Berlin'; export TZ
to the file '.profile' in your home directory; then log out and log in again.

Here is that TZ value again, this time on standard output so that you
can use the /usr/bin/tzselect command in shell scripts:
Europe/Berlin
[root@localhost mercury]# date
Wed Dec  4 00:53:35 PST 2013

 

************

 

it still shows 00:53 but now i germany it's 09:53 ,

 

i then checked here:

 

[root@localhost mercury]# vi /etc/sysconfig/clock

and changed there ZONE="America/Los_Angeles"

to ZONE="Europe/Berlin"

 

and did a reboot.. let's see :

 

still shows wrong :

 

[root@whde-srv11 mercury]# date
Wed Dec  4 01:04:07 PST 2013
[root@whde-srv11 mercury]#


any further tweaks , we dont mind the am/pm format , it would help if just the german time would appear there

 

regards

ben

 

Regular Contributor I
Posts: 190
Registered: ‎04-27-2009

Re: Change from 12am/pm to 24hour format , germany

if using this command :

 

[root@whde-srv11 mercury]# ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime
[root@whde-srv11 mercury]# date
Wed Dec  4 10:07:51 CET 2013
[root@whde-srv11 mercury]#

 

it shows then the correct time , also in system-performance .. also in the client-tab , that would help . let's see if it works after rebooting ;-)

Regular Contributor I
Posts: 190
Registered: ‎04-27-2009

Re: Change from 12am/pm to 24hour format , germany

Ok this seems to work , if you "restart amp" then an error will occur, i had to completely reboot the AMP and now the correct time is still there.

 

so is this some valid workaround?

 

summarized , i only did this now :

root@whde-srv11 mercury]# ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime
[root@whde-srv11 mercury]# date
Wed Dec  4 10:07:51 CET 2013
[root@whde-srv11 mercury]#

 

and here's still Europe/Berlin ... so this stays also after reboot :

 

[root@whde-srv11 mercury]# cat /etc/sysconfig/clock
ZONE="Europe/Berlin"
[root@whde-srv11 mercury]#

regards

ben

Moderator
Posts: 1,252
Registered: ‎10-16-2008

Re: Change from 12am/pm to 24hour format , germany

Word of caution: AirWave is very sensitive to time changes (as all data is referenced to a locale time stamp or epoch value).

 

With that in mind, instead of using TZselect, I usually refer users to re-use the time setup that occurs during initial system install:

# /root/svn/mercury/install/time-setup

 

Data in the database and RRDs are using epoch time values while most logs use locale time stamps, so be very careful not to make a mistake and put yourself into the future.  It's okay if you put yourself in the past, the visible side effect of moving backwards in time is that no new data will be recorded until it passes that last recorded update in the RRD.  So if time was moved back an hour, new data would not be seen until the system time passes the last recorded data point.  But if by accident the time is set a year in the future and then set back to current time, the RRDs will have updates to that future time and won't record new data until that time is passed.  The solution there is to either blow away all RRD data and start from scratch, or restore the last backed up data from a nightly backup.


Rob Gin
Senior QA Engineer - Network Services
Aruba Networks, a Hewlett Packard Enterprise Company
Search Airheads
Showing results for 
Search instead for 
Did you mean: