Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Windows/foobar Timestamps and daylight savings time (Read 1186 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Windows/foobar Timestamps and daylight savings time

I'm beating my head against the wall with some timezone/daylight savings time issue related to handling/converting timestamps in foo_enhanced_playcount.

My test case:
Foobar says I played a song on: 2019-11-01 12:32:28 before daylight savings time expired.
My component takes retrieves that timestamp string (using %last_played%) and then converts it to a foobar/windows timestamp using foobar2000_io::filetimestamp_from_string. That gives a value of 132171067480000000 which I store in the metadb.

I call format_filetimestamp::format_filetimestamp on 132171067480000000 and get: 2019-11-01 12:32:28 which is exactly what I'd expect.
However, that foobar/Windows timestamp seems to be wrong.

Plugging that into an online converter, or using pfc::fileTimeWtoU(132171067480000000) gives a unix epoch time of 1572633148 (multiply by 1000 for a JS timestamp). That is equal to a time of 2019-11-01 13:32:28 which is one hour greater than it should be (or precisely the difference since daylight savings time ended). In fact, if I do this conversion on songs scrobbled AFTER daylight savings time ended, the values are identical throughout.

I also retrieve the scrobbled time from last.fm (in epoch time) of 1572633106 and convert that to windows time using pfc::fileTimeUtoW() which returns 132171067060000000. That returns 2019-11-01 13:31:46 which is again 1 hour greater than I'd expect.

I think what's going on is that format_filetimestamp::format_filetimestamp is returning incorrect values based off of current timezone settings and not historical timezones when it was scrobbled which causes the discrepency. @Peter can you verify that's the case? This definitely seems wrong to me.