Wireless Access

last person joined: 14 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

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

This thread has been viewed 1 times
  • 1.  Change from 12am/pm to 24hour format , germany

    Posted Dec 03, 2013 10:55 AM

    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



  • 2.  RE: Change from 12am/pm to 24hour format , germany

    EMPLOYEE
    Posted Dec 03, 2013 03:53 PM

    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.



  • 3.  RE: Change from 12am/pm to 24hour format , germany

    Posted Dec 04, 2013 04:05 AM

    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

     



  • 4.  RE: Change from 12am/pm to 24hour format , germany

    Posted Dec 04, 2013 04:10 AM

    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 ;-)



  • 5.  RE: Change from 12am/pm to 24hour format , germany

    Posted Dec 04, 2013 04:19 AM

    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



  • 6.  RE: Change from 12am/pm to 24hour format , germany

    EMPLOYEE
    Posted Dec 04, 2013 11:53 AM

    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.