Timezone support in release 2.060315 - any beta testers figure it out?

[Joe L.]

I'm one of the beta-testers of release 2.060315.  One of the new features is support for setting the time-zone from the unRaid web-based management utility.

 

I don't think it is working properly.

 

Now... I can test the effect of the management screen time and timezone fields by using a "date" command in a telnet window.

 

So ... first I use the "date" command in the telnet window

 

root@Tower:/var/log# date

Wed Mar 22 00:27:55 GMT 2006

 

I then check the management screen.  It shows GMT as the time zone, but shows 3/21/2006 4:27:43 PM as the current time.

Now, GMT matches, but 4:27PM is 4 hours prior to the date shown in the telnet window.  Why is there an offset?

 

OK, now I change the timezone using the management screen to GMT-4 and press "APPLY"

 

The screen refreshes, the timezone is now GMT-4 and now the datetime it shows is 3/21/2006 12:27:43 PM 

I'm a bit confused... the time shown on the management screen changed 8 hours, not 4.

 

I then try the "date" command from the telnet window.

root@Tower:/var/log# date

Tue Mar 21 16:37:26 GMT+4 2006

 

OK... it changed... from 00:27 on the 22nd to 16:27 on the 21st.  again a difference of 8 hours.  Now

All I did was change the time-zone.  It appears as if the offset is being applied twice.

 

OK.. lets leave the timezone alone and try to set the time from the management screen.

 

Currently, the management screen shows 3/21/2006 12:39:14 PM with a timezone of GMT-4

The "date" command in the telnet window shows:

root@Tower:/var/log# date

Tue Mar 21 16:39:16 GMT+4 2006 

the time differs by 4 hours.  Is the management screen trying to show me UTC?  Note that the date command shows GMT+4 while the management screen shows GMT-4

 

Ok, now I want to set the time and leave the timezone allone.

I use the management utility to set the time field to 3/22/2006 09:19:00 PM and leave the timezone setting at GMT-4 and press "APPLY"

 

The screen refreshes... the timezone stayed at GMT-4, but the "current time" now shows 3/22/2006 5:19:00 PM (4 hours earlier than where I just set it.  I did NOT expect it to change from the value I just entered  )  Lets see what the "date" comand shows in the telnet window...

 

root@Tower:/var/log# date

Wed Mar 22 21:19:34 GMT+4 2006

 

Seems to me the UNIX time is where I set it (9:19 PM) but the timezone is set to plus 4 rather than minus 4 hours.

 

Tom,  might this be a bug with the new timezone feature?  I can't set the time from the management utility and have it show me the same value I set.

 

Joe L.

 

 

 

 

 

 

[unraider]

I'm not a beta tester but still probably can help you...

 

The difference between Wed Mar 22 00:27:55 GMT 2006  and 3/21/2006 4:27:43 PM is not 4 hours... see carefully, the former is 22nd Mar, 00.27 (am), (as in 21st Mar late night), the latter is clear - 21st Mar, 4.27PM... so the former is 16 hours ahead of latter...

 

I'm sure rest you can figure it out...

 

 

[erikatcuse]

Joe

 

I noticed yesterday that my time was off so I changed the management utillity I was then rechecking some bios settings and noticed my bios clock was a full 12 hours off.  Apparently the bios clock is in 24h format and I changed it back.  Later on the unraid software was off, you guessed it 12 hours off.

 

So I think in order for the unraid clock to work you need to set your bios time to gmt time.

[limetech]

Yep, there's a bug    Actually, it's sorta working... If you go to the managment page and set a time and timezone, the page will show the wrong time if you change the timezone, but if you exit the Management Utility (i.e., reboot), when it restarts you will find that the time and timezone you set are now correct!  (Had to plow through the source of localtime() in glibc to figure this one out; I can give the gory details if anyone is interested.)

 

So the workaround is this: First go to the Management Utility and set your timezone, then Stop array and click Reboot.  When system is back up, go to Settings and set your local time.

[Joe L.]

The workaround is still a bit confusing...

 

I set the timezone to GMT-5 and the datetime to 3/23 6:29:00 AM, set the time by pressing "Apply" then stopped the array and rebooted

 

The management screen now shows GMT-5 (good) but it shows the time as 3/23 9:40:59 AM when I checked after the unRaid server rebooted.

 

Logging in a telnet window as root I type "date" (a few minutes later) and get

Tower login: root

Linux 2.4.31.

root@Tower:~# date

Thu Mar 23 09:47:06 GMT+5 2006

 

Now, the time seems off by 3 hours from where I set it.   The time-zone appears to be GMT PLUS 5 rather than GMT MINUS 5.

 

So I still did not get the time set to where I wanted...

 

As a final test I create a file on one of the unRaid disks and look at it from a windows box like this:

 

date >/mnt/disk1/test_date.txt

 

In windows explorer it shows a modified datetime of 3/23/2006 at 9:59 AM

 

Opening it in notepad the contents of the file (the output of the unix date command I used to create it) are: 

Thu Mar 23 09:59:11 GMT+5 2006

 

 

looking in /etc I see the following:

-rw-r--r--  1 root root    58 Mar 23 09:33 localtime

lrwxrwxrwx  1 root root    29 Mar 23 09:33 localtime-copied-from -> /usr/share/zoneinfo/Etc/GMT+5

This seems to confirm the PLUS 5 vs. the MINUS 5 hour offset I intended from UTC.

 

Lastly since internally Lunix keeps UTC time and everything else is for display only..,

root@Tower:/etc# date -u

Thu Mar 23 15:17:41 UTC 2006

Looking on the web using a browser, the current UTC time is 12:17 PM on March 23rd.  (about 3 hours off from my server's idea of UTC)

 

Finally, from the telnet window I set the UTC time using the date command (this eliminates the timezone as a factor)

root@Tower:/etc# date -u 03231250

Thu Mar 23 12:50:00 UTC 2006

and then see the effect by invoking the date command once more...

 

root@Tower:/etc# date

Thu Mar 23 07:50:09 GMT+5 2006

 

Looking at the management utility (pressing the refresh button on the browser) I see the correct time (finally) and even GMT-5 as the offset (finally)

 

I'm so confused... (glad you were able to look at the source of localtime.c to figure it out)  There appears to be more than one issue.  The three hour difference from what I intended to set the time, and also the GMT offset from localtime of PLUS vs MINUS.

 

Joe L.

 

 

 

 

[limetech]

So the workaround is this: First go to the Management Utility and set your timezone, then Stop array and click Reboot.  When system is back up, go to Settings and set your local time.

 

There are two steps to the workaround:

1. Set your timezone (forget about the time), Stop arrary, Reboot, then

2. Set your local time.

 

The 'localtime-copied-from' link is correct.  The way the timezone files are named in '/usr/share/zoneinfo/Etc' is misleading.  The numeric offset after "GMT" in the file name represents the number of hours you must add to your local time to get GMT for that timezone.

 

Joe, here's the bug.  There is a "first_time_called" flag in the function localtime().  The first time a process calls localtime(), the code reads the timezone info from the file /etc/localtime.  BUT, subseqent calls to localtime() do NOT re-read the file.  When you change the timezone in the Management Utility, all it does is change the /etc/localtime file (and /etc/localtime-copied-from).  So the running process (Management Utility) timezone conversion is messed up.  (The fix is for the Management Utility code to call tzset() after changing the localtime file.)

[Joe L.]

Tom,

 

Glad the fix to the management screen was easy. (add tzset() when timezone is changed)

 

The 'localtime-copied-from' link is correct.  The way the timezone files are named in '/usr/share/zoneinfo/Etc' is misleading.  The numeric offset after "GMT" in the file name represents the number of hours you must add to your local time to get GMT for that timezone.

OK... (dumb, but OK)   I checked a few more web-sites and at least one Linux distribution recommends NOT linking to the GMT timezone files as they are misleading..  That page in fact said: Please avoid the /usr/share/zoneinfo/Etc/GMT* timezones as their names do not indicate the expected zones. For instance, GMT-8 is in fact GMT+8.

 

The first time a process calls localtime(), the code reads the timezone info from the file /etc/localtime.  BUT, subseqent calls to localtime() do NOT re-read the file.

That make sense, the timezone rarely changes between calls to the localtime() routine and it would be pointless to re-read the file every time.   

  When you change the timezone in the Management Utility, all it does is change the /etc/localtime file (and /etc/localtime-copied-from).  So the running process (Management Utility) timezone conversion is messed up.  (The fix is for the Management Utility code to call tzset() after changing the localtime file.)

Thanks for clearing up the confusion.   It is still very confusing when looking at the output of the Linux "date" command to see GMT+5 when I know I'm GMT-5 and that is what it says on your management screen drop-down list.

 

Perhaps a FAQ question/answer on your web-site is in order.

 

Joe L.

[limetech]

The timezone stuff is a bit problematic.  Including all the various timezone files would take up nearly 5MB on the Flash and require a fairly elaborate user i/f.  Not only that, but many timezone files become quickly obsolete because many local laws defining daylight time change yearly.

 

So the roadmap for timezone support is as follows:

 

1. Implement "standard" timezone selection without regard to daylight time.  This will ensure timestamps are correct, but you must manually adjust the time on daylight/standard transition dates. This is the support we have now - excpet for the bug    [but we'll fix the bug before making the release generally available]

 

2. A future upgrade will permit you to copy a "custom" timezone file onto the Flash.  We would make all the "current" timezone files available on our website (or links to them).  You would select the one for your locality, download it, and copy to the Flash.  Then the server would use that timezone file & be able to automatically ajdust for daylight time transitions.

[Joe L.]

Tom,

 

That sounds like a good roadmap to me.  Thanks for the clarification.

 

I'll continue with my beta-testing tonight... 

 

Joe L.

[BLKMGK]

Okay, so I'm NOT crazy! I was just noticing that my file times were off again and about go nutz (lol). Very glad to see this is being worked and that I didn't have to expend brain cells pondering it much. Thanks for working on a fix, it really is vexing to write to a file system and have the time be so far off when you look at it later.