I was only able to find one post about problems with Date & Time.  I followed suggestion of

1) Set Timezone first

2) Stop array and reboot

3) Set local time

 

This seemed great, but the next time you reboot the time jumps forward three hours.  When I rebooted again, it jumped forward another three.

 

Is there a workaround?  Does it matter if Bios is set to 12 or 24hr clock?

... I am running unRaid v3.0

 

Thanks!

I am having the same issue.  I never noticed before with other motherboards. Anyone else have this problem or a potential work around?

I can confirm that this happens on my Beta 2 tower.  I have not booted my 3.0 Final in a while and the time is right on that one.

I am experiencng the same issue with 3.0

 

 

I've rebooted my unRAID server (3.0 final) several times and the time is still spot on.

I've rebooted my unRAID server (3.0 final) several times and the time is still spot on.

 

Hrmmmm.  What is your timezone set to? Mine is +5GMT.

oops..    I just double-checked and it was the right time 9:13....just not the right 12 hour period or date (i.e., it was 12 hours ahead).  Guess I wasn't looking closely enough.

 

I've set mine to GMT-5:00.  As soon as it finishes copying a large number of video files (i.e., tomorrow a.m.), I'll reboot it and see what happens.

 

P.S.  hypyke...if you're on the East Coast, should your timezone be set like mine (GMT minus 5 hours).  I got my info here:

 

http://wwp.greenwichmeantime.com/

P.S.  hypyke...if you're on the East Coast, should your timezone be set like mine (GMT minus 5 hours).

 

Oops.  That is what I meant.  -5GMT. 

Well...I just checked my setup (3.0 final) and it appears to be doing it for me as well.  :'(  It doesn't matter whether I power down and manually start it up or just reboot.

 

I'm using the time as reported by unRAID in the Server Management Console/Settings tab.  After rebooting once, I even went into the BIOS, hoping the problem was just with unRAID, but no joy...it was wrong too.  How does one check the "time" in Linux (i.e., at the root command prompt)?  I looked up the Unix commands "time" and "times", but neither of them appears to be what I'm looking for.

  How does one check the "time" in Linux (i.e., at the root command prompt)?  I looked up the Unix commands "time" and "times", but neither of them appears to be what I'm looking for.

The Unix/Linux command you are looking for is "date"  (without the quotes)

 

Joe L.

The Unix/Linux command you are looking for is "date" (without the quotes)

 

Thanks Joe.  Here's a little experiment I ran:

 

• Step 1:  I correctly set the date/time of my motherboard's BIOS (Asus P5PE-VM, BIOS v02.53), saved the result and rebooted the server.
  
• Step 2:  I ran "Setup" again, double-checking that the date/time was still correct (it was), saved the results again and rebooted the server.
  
• Step 3:  I let unRAID boot up, logged in as root and ran the "date" command.
  
• Step 4:  I fired up my workstation's browser and checked SMU's Settings tab to see what date/time it reported.
  

 

Here are the results:

 

• Step 2:  System Time - 20:13:xx; System Date - Mon 01/08/2007 (this is correct)
  
• Step 3:  Mon Jan 9 23:14:xx GMT+5 2007 (this is incorrect, time has somehow advanced three hours; the time zone is also wrong)
  
• Step 4:  Current data & time - 1/8/2007  11:15:xx PM; Time zone - (GMT-5:00) (the time is three hours ahead, but the time zone is correct)
  

 

I could successfully reset the time within SMU's web page and it would "take" according to the Linux "date" command, but that still leaves the original mystery.

 

Billk

 

 

 

Asus P5PE-VM

 

I have the same motherboard and the same problem.  I'm running Unraid basic v3.0

 

 

If you forget about trying to set date/time via bios, and just use the SMU Setting page, it should retain correct time across re-boots.  If this does not work, please post results back here.

 

We're re-working this somewhat in order to interoperate with an NTP (Network Time Protocol) server.

 

The way it works right now is that the bios is assumed to be set to LOCAL time.  In conjunction with the timezone setting in the 'ident.cfg' file, the system is able to calculate UT.  Unfortunately, we really need a 'Daylight time in-effect' checkbox as well, so that fix as well as NTP support will be added.

If you forget about trying to set date/time via bios, and just use the SMU Setting page, it should retain correct time across re-boots.  If this does not work, please post results back here.

 

Sorry, but the results were the same.  The test:

 

• Step 1:  I fired up my workstation's browser and set the correct date and time on SMU's Setting Page.
  
• Step 2:  I used the buttons on SMU's Main page to "Stop" and "Shutdown" the server.
  
• Step 3:  I powered the server back up.
  
• Step 4:  I logged in as root and ran the "date" command.
  
• Step 5:  I fired up my workstation's browser again and checked SMU's Setting page to see what date/time it reported.
  

 

Here are the results:

 

• Step 1:  Current date & time:  2/11/2007 5:14:08PM, Time Zone:  (GMT-5:00) (This is the correct date/time I mentioned above)
  
• Step 4:  Sun Feb 11 20:19:56 GMT+5 2007 (incorrect time - - i.e., it's advanced three hours - - and incorrect time zone)
  
• Step 5:  Current date & time:  2/11/2007 8:21:38 PM, Time Zone:  (GMT-5:00) (incorrect time - - i.e., it's advanced three hours - - but correct time zone)
  

 

I tried repeating the test, this time rebooting the server instead of shutting it down, but received the same results.  It appears that something in unRAID's boot-up sequence is causing the MB's BIOS to advance three hours.  I am now running version 3.1-beta 2.

 

Wow I'm glad to read this, I thought I was going crazy.  I just reset the time in the gui after rebooting.  Luckily I only reboot every few months.  Maybe the next release will fix this?

 

 

Tom,

 

Is there any further testing you'd like me to do?

 

Bill

I'll look into this further.  Thanks.

I'm happy to report this issues appears to have been resolved in unRAID 4.0-beta10 (I suspect it was first fixed in the first 4.0 beta code drop, but I was too busy to test until now).