It would need more investigation, but it also seems wonky on when a browser thinks another day has gone by. I’m pretty sure I noticed my android client changes differently from the PC.
Is your NUC running ROCK, or is it on Windows? ROCK uses UTC, so I wonder if this, coupled with your timezone, is causing the issue? Over to the @support team, I think…
My first thought was about a UTC issue. Another data point is that all my (but not my wife’s) PCs dual boot linux and I have windows configured to use UTC so it plays nicely with linux.
I can’t imagine why that would matter though since I doubt Roon is looking at how the BIOS is keeping time. Am I wrong that the OS (windows or linux) would internally keep time the same way regardless of how it’s stored in the BIOS? (it just does the appropriate conversion at boot)
The team has been trying to reproduce this behavior but so far they have not been able to. They’re hoping you can confirm what time zone you’re in and share a file with us that is experiencing this issue so we can try to reproduce that way. You can share the file with us via a shared Dropbox link.
Sorry for the delay, I wanted to re-check a bunch of things.
So the deal is it’s still not right. The “Added” date is always one off the tag. Now, I did see the handling isn’t consistent. I’ve tried it on 5 Windows PC (windows 10 and 7) and they all get it wrong. My wife’s ipad gets it wrong. However, my two android devices get it right.
Thanks for the info, @Ken_Lesniak. I’ll be sure to update your ticket with this and attach the sample file and I’ll pass it over to the team. I’ll reach out once more when they’ve done some further testing.
I spoke with the team about the current status of this investigation. So far we have not been able to successfully reproduce this issue in our QA labs, so the team is hoping you might be able to provide some further information.
What app are you using to tag your files? What OS are you using this app on?
If you temporarily use a Windows device as your Core do you see the same issue?
On the first question, I use foobar on windows 7 for tagging.
I’ll try the second one and report back when I get a chance.
An intersting related note. Just yesterday I was adding a new CD. I rip externally and copy into Roon. When I went into Roon to check out the new rip, it showed “added today”. First time I had ever seen that. So I go and back to windows, add IMPORTDATE and recopy, and viola, back to it being a day off.
Do you have any devs in the orlando area? I’d be happy to demo in person.
I’m not here to claim that I know what’s going on, but as a fellow programmer on occasion, I know that the correct handling of time/date values is one of the harder things to get right.
What do we know? Roon officials have stated in the past that Roon is using UTC internally. This means that times have to be converted – depending on OS and/or what gets read in – before they get stored in the DB and then again after they get read out from the DB, should they be presented to the user. Historically there where errors in the process on many occasions where Roon displays times to users. Some got fixed over the time, some are still present in Roon.
The first three options for Import Date are all actually timestamps and not pure dates and as such have to undergo the time conversion(s) described above. So maybe they use the same code path for the fourth option (IMORTDATE tag) too? What happens when a user provides just a date then? Maybe a time just gets added, something like 00:00:00? Combine that with a time conversion error – which were/are so typical for Roon – and, depending on a users actual TZ, you’re easily a day off. As it’s unclear how the code in Roon works if it gets a date only, I long ago switched to entering timestamps in my IMPORTDATE tags, usually using 12:00:00 as time value.
Thanks for the in depth reply. I appreciate someone puzzling on it.
I’m an ex software guy, so yeah, time/date conversions and handling is fussy. Not rocket science. If you can do things like Valence, maybe you should be able to get dates right. Besides the conversions, you’re going to have to do “date math” too.
That IMPORTDATE would allow a time makes sense now that you mention it, but I unfortunately was taking the name literally. Too bad it’s no longer in fashion to actually specify what software does or doesn’t do.
I have noticed some funny behavior with what’s reported back by Roon depending on when I look at it. I however haven’t had enough time to invest in it to make a statement other than that–just too many other things to do. It may be of note that I usually end up adding things to my Roon library +/- midnight localtime.
You mention that you switched to adding the time value–was it because you were having problems or just because you had other problems with dates and hoped to avoid one here?
I suppose I could script up something with metaflac to update my library, but it’s a lot of manual work since I have a working copy, my archive and then what’s on Roon (which needs to be converted from the single file flac’s I keep in the other two places).
One thing I’ve wondered about in dealing with this is what time does my ROCK system think it is? Does it just get the time from the BIOS? If so, what should it be? Localtime? UTC? I don’t recall seeing any mention of that in setting up a NUC with ROCK (perhaps I’m just forgetting, that’s been known to happen).
And as noted in my previous reply, I tend to add things to my Roon library around midnight. And I was thinking the same thing that I needed to experiment with some different times.
Most likely because of observing something similar as you are seeing right now. I can no longer remember the details exactly.
As with so many things, it’s a complicated process. If an OS boots up, it doesn’t know about time. On PC hardware the (battery buffered) RTC is then used to derive of a first sample of time. While Windows defaults to local time here, all the UNIX and LINUX systems I’ve used so far default to UTC (at least if no Windows is detected on the same machine). Wrong time can be detected and corrected later on as soon as the network is ready and internet access available by using NTP do derive an independent time sample. UTC is usually set as the default TZ on UNIX/LINUX systems. As ROCK doesn’t allow a user to make changes to the system and AFAIK doesn’t allow to set the TZ in it’s web UI also, i would therefore assume it’s (still) UTC. See also:
