[Bug] Bandwidth Usage Reports are 12 Hours Out

Ok, I finally got a chance to look at this in a bit more depth.  This is what I've just done:

At the time of my investigation the local time was 20:30, 7 June 2012 
- Set my Astaro timezone and time/date to the correct local time
- Rebooted the firewall and checked the bios clock, it was set to 08:30, 7 June 2012 (12 hours slow).
- Changed the bios clock to 20:30, 7 June 2012 & booted up Astaro.
- The Astaro clock showed as 08:30, 8 June 2012!  (12 hours fast).
- Set the time in Astaro to 20:30, 7 June 2012, rebooted.
- Checked bios clock - 08:30, 7 June 2012 (12 hours slow)
...

So... it seems that Astaro is somehow getting confused and adding 12 hours (which just happens to be what my timezone is; UTC+12) to the bios clock time.  This is quite annoying.  I could probably confirm by setting a different timezone in Astaro and then seeing what affect this has on the bios clock, but that would require more reboots... [:)]  It's almost like Astaro sees the BIOS clock as UTC...

AFAICS there is no 'timezone' setting in my firewall computer's bios settings.

In any case, this theoretically should all be moot because Astaro should refer to it's own time for everything and so there should never be any issue.  However, perhaps there is some code (eg; bandwidth usage reports) which refers to the bios clock instead of the Astaro time??

The problem is not the time set in your BIOS; that time is being maintained (reset) by the Astaro at UTC time... since you are in New Zealand, your local time is 12 hours off (+) from UTC.  It's absolutely normal for that time to be different -- in most of the BIOS I see, there's not even a place to set the Time Zone you are in, that's handled by the OS.

There is probably a bug (it's happened before, as you noted) where the reporting module is using UTC instead of your local time for the reports.

It may just be a DB issue, etc.  If you had a commercial license, I'd tell you to start a case with support.  However, I'll check to see if this bug affects me or any of my customers, if it does, I'll start a case.

The problem is not the time set in your BIOS; that time is being maintained (reset) by the Astaro at UTC time... since you are in New Zealand, your local time is 12 hours off (+) from UTC.  It's absolutely normal for that time to be different -- in most of the BIOS I see, there's not even a place to set the Time Zone you are in, that's handled by the OS.

There is probably a bug (it's happened before, as you noted) where the reporting module is using UTC instead of your local time for the reports.

It may just be a DB issue, etc.  If you had a commercial license, I'd tell you to start a case with support.  However, I'll check to see if this bug affects me or any of my customers, if it does, I'll start a case.

The problem is not the time set in your BIOS; that time is being maintained (reset) by the Astaro at UTC time... since you are in New Zealand, your local time is 12 hours off (+) from UTC.  It's absolutely normal for that time to be different -- in most of the BIOS I see, there's not even a place to set the Time Zone you are in, that's handled by the OS.

Hmm, Windows must do things differently then as I have not seen this behavior on Windows boxes before.

There is probably a bug (it's happened before, as you noted) where the reporting module is using UTC instead of your local time for the reports.

It may just be a DB issue, etc.  If you had a commercial license, I'd tell you to start a case with support.  However, I'll check to see if this bug affects me or any of my customers, if it does, I'll start a case.

Awesome, thanks! [:)]

Yeah, Windows is different.  On Linux I think you have the option to keep the BIOS at UTC or not... I think the default on ASG installations is UTC (If I recall correctly, there's even a checkbox for it that you can select or deselect during the manual software install process).