Hi
Is it possible to set the local time zone on a NUC running ROCK?
If it isn’t, would it be safe to assume that any alarms I’ve set using the alarms extension, are set to UTC time, not local time?
TIA Peter
The Alarm Clock extension uses the local time of the device it is running on. In your case the RPi running DietPi. This means that if you configure the correct time zone using dietpi-config, alarms can be set using local time.
Don’t believe you can install extensions on Rock.
Thats true, but you can install the on something like a Raspberry PI which is on the same network & they’ll become available to the Rock.
Yeah, its just that the OP was talking about Rock on a NUC and using the time settings on the NUC, not using a RPi…Anyhoo I am sure he has got all the info he needs now. 
the display on the Logitech Transporter shows GMT time not local
Old Thread - still current question. ROCK is evidently running in the wrong time zone (its one hour off), and the Squeezeboxen get their time from the Roon core…
It would indeed be very handy to be able to set the TZ…
Hello,
Is there an answer to the question about setting the TZ?
This would be nice to set backup schedule to happen in your TZ vs. the TZ that is default in the Nucleus.
1 Like
There does seem to be a TZ setting in the advanced option of the unit but nothing drops down.
Terry
Has this issue been solved? If so, how do I set my ROCK to be in my local time zone?
I searched on this as I too was having the same issue. Putting this in an old thread for that reason.
I believe the solution is to change the time in the NUC Rock BIOS. Hook up USB keyboard, and HDMI monitor and hold F2 during boot up to get into BIOS, change time, save changes, exit.
I did that long time ago (set the correct.time.zone in BIOS), but once I restarted ROCK and check the time in the BIOS again, the time is back to wrong time zone again for me. I think it was set to GMT.
Judging by when my Backups kick off, my ROCK running on a NUC has my local time. I’ve never set anything, BIOS or otherwise.
I raised this issue a while back, Problem in total hours in "Recent listening" counter
And this morning, before 7am my time, I played a file on purpose just to see if it would show up in today’s counter, and it did not. It shows up on yesterday’s counter. But, if I played anything after 7am, it would show up on today’s counter. My local zone is GMT+7 therefore I concluded that the counter is somehow based on GMT not local time.
The correct system timezone (BIOS) for UNIX and Linux based machines is UTC (mostly the same as GMT) since, I’m not sure, forever. It’s up to the applications/programs to translate time and date values into a users local timezone. So it’s up to Roon Labs to fix time/date handling/display for Roon in areas where it is currently wrong. Obviously does fixing the Recent listening (introduced with Roon 1.8) not have a high priority or it would have been fixed by now (currently at Roon 2.0).
2 Likes
Out of curiousity, I plugged my NUC to a monitor and noticed that the time was already set to GMT. I set the time to my local time, saved the BIOS setting and restarted ROCK. After I got an IP address, I restarted ROCK from the Web UI and then boot to BIOS again and checked that the time in the BIOS was set back to GMT again.
This is expected behavior.
Could you elaborate why? I am still rather curious.
Thanks.
Because you set a wrong system time. As soon as Roon OS (same with any modern OS by the way, so not Roon related) connects to the internet it gathers time information from internet time services and sets the system time to the correct value (what the correct value for system time is, may vary between Microsoft and and all the other popular OSes though). The non-volatile memory location for the system time is the Real-Time-Clock (RTC) on the mainboard (BIOS clock).
Expected behavior by who? It’s wrong to my local time and there’s no way to set the time zone so there’s no option given to an end use? It’s either GMT or the highway apparently. So the listening time that works on Roon on every other OS platform works differently on ROCK and there’s been no attempt to fix it with a time zone setting?
1 Like