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 (https://www.epochconverter.com/ldap), 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.