Skip to main content
Topic: Windows/foobar Timestamps and daylight savings time (Read 62 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.

 
SimplePortal 1.0.0 RC1 © 2008-2019