My new Nucleus+ is putting the wrong time on new imports. I’m ripping a bunch of CDs onto my MacBook Air (which has the correct time, obvi) and copying the files to the external SSD on which I have my local files, and Roon is logging the “import date” as UTC instead of my local time zone, which is UTC -6
How do I correct this? I know how to fix the individual files after the fact but how can I get it to put the correct time stamp on them in the first place?
Use the IMPORTDATE file tag and allow Roon to use it:
Thanks. I checked and it was already enabled. No such tag exists in dbPoweramp so I created one and ripped a CD but it still is putting things in there 6 hours ahead of actual time ripped.
Bummer. Small thing, but it’s the 2nd unpleasant surprise with this device; issues I just didn’t have with my Mac.
But I do appreciate the assist. I’ll keep digging.
You likely use ExFAT on the external HD whose timestamps are ultimately broken (different OSes/drivers interpret them differently). The issue you see with the file tag is basically the same as with the file system timestamps – they are unqualified and so the software chooses the interpretation it “likes” the most. Unlike the file system timestamps though, the file tag is provided by the user and it should be relatively easy to correct the value for the deviation before entering – alternatively: give up on minute precision and just enter a time value that’s save to be on the “right” day at least.
PS: Other file systems than the FAT based ones might behave better when it comes down to timestamps and their interpretation.
OK. Makes sense.
Yes, I formatted the external drive connected to the Nucleus as ExFAT because, I thought, that was the recommendation for most compatible. It had been previously formatted APFS, and I didn’t think the Nucleus would be able to add files to it, even copied over a network.
I’ll keep experimenting. Thankfully, I don’t have 100s of CDs to rip but I do have about 30
ExFAT is possibly the most compatible for the data stored on it, but not for “unimportant” metadata like for example timestamps. Sad but true.
If I format it back to APFS in Ventura, will I be able to copy files to it from my computer over the network?
I also use this SSD as one of my backup locations for my database, so the Nucleus has got to be able to write to it.
I don’t think so, it’s not listed in the manual.
PS: And VFAT/FAT32/FAT16 are like exFAT FAT based – so leaves you with NTFS and the compatible (to ROCK/Roon OS) EXT variants.
Thanks very much. I believe I will plan to lower my expectations and let my music live 6 hours in the future 
Different file system formats and operating systems can cause time zone issues. But not sure that this particular issue has anything to do with file system formats.
As far as I understand, the time on the Nucleus is always UTC and cannot be changed. So anything that the Roon core logs will always be according to UTC. I have a Nucleus+ and I am on eastern US time. So for example, my “Recent Listening” will always record anything I listen to after 7pm as though I listened to it the following day. I don’t have examples of a file import since I usually don’t do any importing in the evenings. Is there a way to see the actual time that a file was imported to Roon? I can only see the date.
Not that I could see within Roon. I could tell from the timestamp on the computer I was copying from.
The reason I noticed was that this was in the evening on 12-31-2022 and the files were being shown as added on 1-1-2023.
It isn’t a major problem but just an odd and unexpected one given the price of the machine. I have zero experience with Linux. A $599 Mac doesn’t do this.
Thanks!
All modern OSes use UTC internally, then it gets converted for user-visible output according to the time zone setting (which isn’t a fixed property but can change). That’s the same for macOS, Linux, and I think even Windows these days.
Seems to me that RoonOS left out the time zone handling subsystem on the Nucleus, which makes sense as it isn’t a simple thing, and the Nucleus promises to use all resources for Roon. Time zone handling needs information about all time zones and daylight saving, which changes all the time in some part of the globe and hence must be updated frequently, so one would have to add a lot of stuff. Plus, just like for macOS and Linux, the base OS is not the right place for this.
The Roon equivalent of the macOS Finder is the Roon remote GUI, and that’s where time zone conversion should take place. I don’t know if it does it correctly, but it would be where it should happen
I wish that when I save an album link from both Tidal and Qobuz back to back, Roon would use my local date and time. It’s a non-issue if I’m only linking one specific album, but if I do several, then I see all the Qobuz first, then all the Tidal’s next. I just yesterday learned how to edit the date, but it’s a pain with 3000 albums. Of course, most are OK already, but I will eventually get them all aligned.
Indeed, and if I play an album on Jan 1, 00:01, it should record the play time like this and not a few hours back into the old year (I didn’t check what it does). But all of this should be handled in the remote, not in the Nucleus. The Nucleus knowing only UTC makes sense. The file date stamps on the Nucleus’s internal storage would then also have to use UTC and in an ideal world this would be translated by SMB to the time zone of the client that is viewing them (different clients could be in different time zones as well), but I don’t know if that’s possible in SMB
I don’t worry about play time and play count, etc. But, I do like my library sorted in a meaningful way.
Everyone will have their pet peeves with incorrect time stamps, but all of them would be fixed by correct handling of time stamps 
Anyway, the root of this discussion was that Doug expected the Nucleus to be time zone aware, I am just stating that this would be the wrong place to do it as the only sane way on the OS level is to use UTC. It’s the UI that is responsible for timezone translation.
Yeah, I knew there was a workaround, but it was unexpected behavior. Then again I have zero experience using Linux. I just figured computers knew what time it was once they connected to the internet, and didn’t think about it much beyond that.
I do appreciate the answers found here, though!
As a long-timer user of Linux on my servers I just wanted to point out that this is not an issue of Linux in general. Install any mainstream Linux distro, and of course your server will manage timezones and will synch the machine time with NTP over the Internet. My Roon Core running on Ubuntu 20.04 server knows what time it is at my place…
Example:
andreas@symphony:~$ timedatectl
Local time: Mon 2023-01-02 15:24:44 -05
Universal time: Mon 2023-01-02 20:24:44 UTC
RTC time: Mon 2023-01-02 20:24:44
Time zone: America/Bogota (-05, -0500)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Your experience is related to how Roon chose to set up Roon OS for the only purpose of running Roon, which is Linux-based, but which ultimately is not a mainstream Linux distro, designed to run near any server application.
They should. This is bush league to only have utc exposed. The extra processing to convert to local time is trivial to the extreme given modern processing power.
This also shows up when you look at hours of music played each day or what you were listening to on any given day. It’s all based on utc.
I filed this in the same weak UI programming that won’t let me change the network name of my rock.
Sheldon
I disagree, but we all have our views (It’s not about the processing power but about adding a whole infrastructure for time zone and daylight savings updates. It’s an appliance. IMHO the GUI should show corrected times, and if play data is wrong, that’s where the issue is.)
But actually I’m replying because DNS names can easily be changed on the DNS server, i.e., your router. My ROCK is known under a different name.