Open-AudIT FAQ describes how to fix the displayed time.
Menu -> Help -> About says UTC which I don't believe because this is on Windows.
c:\xampplite\php\php.ini indeed says Australia/Brisbane and I need to change it. ... see addendum below
I read that OpConfig has a GUI for it but apparently I don't have OpConfig.
Why don't Open-audIT's GUI config pages include time zone setting?
Why doesn't the installer get the time zone from a Windows API and set the default?
Addendum: I changed the time zone to Asia/Tokyo and saved the file. I used Windows's Services GUI to restart Apache 2.2 because apache_stop.bat and apache_start.bat don't work. After these operations, a new log entry appeared, and it's still 1 hour in the future. Now what am I missing?
We installed Open-Audit Version 188.8.131.52, have the same problem
Please see the file
(1) Changed the time zone to Asia/Tokyo
#default-time-zone = "Australia/Melbourne"
default-time-zone = "Asia/Tokyo"
(2) Restart the computer.
(3) Then Open-Audit display the correct time.
Other log lines include audit reports from client PCs when discovering Active Directory. They're all stamped 1 hour later than the actual time of the event.
By the way I didn't see a way to export the system log as a human readable file.
By the way I don't see a way to edit comments that reply to other comments, but I accidentally converted this one which was supposed to be in our conversation below.
The timezone for PHP is set in an .ini file. We override it in c:\xampplite\htdocs\open-audit\index.php and this is where to set it.
We're trying to move away from this and take the timezone from MySQL (which uses the system time much more reliably).
If you're on the latest version of Open-AudIT, check your actual logs (not the help -> about page) and if the time is off let me know.
Please adjust the FAQ page. I adjusted php.ini's line back to Brisbane but should not have touched that file in the first place.
In c:\omk\log, auth.log and opDaemon.log appear to have correct timestamps (Japan time).
index.php ... I didn't install vim in that virtual PC that's isolated from the internet, so just looking with Notepad, I see something that uses Windows APIs. I wonder where the hour inaccuracy comes from.
Where are you seeing incorrect timestamps?
I'm away from that machine today but from memory, it's in the UI page that displays log messages. For example after submitting a discovery operation, the page automatically transitions to the page displaying the log. Each event is stamped 1 hour later than the correct time.
When does Australia switch to daylight savings time? It might be helpful to observe if timestamps after that are 2 hours later than the correct time. (Japan doesn't have daylight savings time.)
Some logs are generated by PHP, others by the command line scripts. Can you post a log line that is the incorrect time.
ALL of the log lines are stamped an hour later than the correct time. I'm away from that PC today but I'll post tomorrow.
Here is an example log line, still 1 hour in the future.
2016-09-29 08:05:50 W2012R2 5068 5 U:Open-AudIT Enterprise C:main F:get_count I:127.0.0.1 M:open-audit_enterprise Active Directory failed verification (html request)
Not sure what version you're using. If you're on the latest then this time is being generated by MySQL. You can confirm it's off by running the following:
mysql -u openaudit -popenauditpassword -e "SELECT NOW();"
If that confirms it, then MySQL is somehow off by an hour. Let me know and I'll see if I can find anything.
Weird. By comparison to the Windows clock in the system tray, SQL is about 59 minutes in the future instead of 60.
By the way, as a newbie I had to search for the mysql.exe program but found it.
If Windows clock is off, then so should MySQL's clock be and therefore the log lines. There's your fix :-)
Sorry I don't understand. If the Windows clock in the taskbar is off, it's off by less than 1 minute. It's not 60 minutes in the future and not 59 minutes in the future. Why is MySQL 59 minutes in the future from Windows?
I know not to complain to a volunteer, but does your silence mean that you're busy elsewhere, or working on this, or that you thought you reported the answer? Is it clear that the Windows clock is not off by 59 or 60 minutes (though I don't know if it's off by a fraction of 1 minute).
Apologies - I misread and thought you meant Windows time was off.
"Why is MySQL 59 minutes in the future from Windows?" - Google....
I'm working on work stuff and checking this when I have the time.
OK, I'll look for an answer in the future 1 hour after you have time ^_^
Google found some non-answers for me so far. If a PHP script is running in a different time zone from the SQL server (i.e. differernt machines in different time zones), or if an admin changes the Windows time or timezone but doesn't restart MySQL. My virtual PC is in Tokyo, running Windows and Active Directory and Open-audIT Enterprise (for learning and experimentation) so all in the same time zone with no changes. I'm suspicious that someone thinks we have daylight savings time so they add an hour.
No it's not a faulty timezone or inappropriate DST conjecture. MySQL is really 59 minutes ahead of Windows.
Tried restarting MySQL?
In Computer Management, Services panel, I restarted the MySQL service. It made no difference,
From another Google search, I tried two more SQL commands.
SELECT @@TIME_ZONE; says Australia/Melbourne which could explain a 1 hour error but not 59 minute error, and I'm not sure where to fix it.
SELECT @@SYSTEM_TIME_ZONE; displays some question marks becaue someone doesn't know how to handle locales correctly. I conjecture that Windows reports the time zone name in Japanese, maybe ???/?? which is Japanese for Asia/Tokyo. Since Microsoft has learned the benefits of scripting I don't really think Windows would do that in an API unless someone forces it to give a localized answer. And next, something else in MySQL tries to convert the string to some non-Japanese locale, which would work if the string had been in English.
Today's log lines are about 2 hours in the future. I think Australia switched to Daylight Savings Time last weekend.
Yes we did.
So we still haven't found the right file to edit to say we're in Japan's time zone instead of Brisbane's, (And it still seems weird that the time zone isn't retrieved from a Windows API.)
So this problem still persists even after 8 Month?
Is there really no solution to this?
Powered by a free Atlassian Confluence Open Source Project License granted to Opmantek. Evaluate Confluence today.