Daylight Savings Time Issue

[bolsinga]

iTunesLibrary returns a Date. The ISO 8601 formatter says it will format it as UTC.

However unchanged play dates from iTunesLibrary will shift by 1 hour when Daylight Savings Time (DST) starts and ends.

Is this correct? I'd expect UTC to be unaffected by DST.

Need to write a sample to learn if iTunesLibrary Date is wrong, or if my assumptions about how ISO 8601 formatter works are wrong.

[bolsinga]

You can see the most recent large change here: https://github.com/bolsinga/itunes_backups/commit/a178b5a242d1d25adce28a8270c831ae7716c60c

[bolsinga]

https://developer.apple.com/forums/thread/767837 it may be the library?

[bolsinga]

Filed FB15767197. It's a real bug. If you run it, save the output, change your mac's time zone, and run it again, it will produce different output, when it should not.

[bolsinga]

https://gist.github.com/bolsinga/c5567318eb03af09d885ed045c687b47 demonstrates the bug in FB15767197

[bolsinga]

In the program's Repair code path, it tries to find this data. Instead of fixing it here, I think it should be fixed at the time when all the stored JSON data is imported into the database. Therefore, I'm going to back out the time offset code.

[bolsinga]

This affects datePlayed, dateAdded, and possibly dateReleased. It's more visible and probably actionable in the flat database (added with #678).

[bolsinga]

The following track was added 9:37 AM PST, and first played 9:40 AM PST. I backed up iTunes into a flat db with PST and then MST. Here is what is there:

bolsinga@Mac itunes_playground % for DB in `ls ~/Desktop/itunes-dst/*db` ; do echo $DB && sqlite3 $DB "SELECT * FROM tracks WHERE itunesid='3222159084106405326';" ; done
/Users/bolsinga/Desktop/itunes-dst/mountain.db
6659|3222159084106405326|Walk On||Neil Young|Young, Neil|On the Beach||1|8|1|1|1974|161133|2025-02-12T16:37:09Z|0|Neil Young|1974-07-16T07:00:00Z||2025-02-12T16:40:51Z|1
/Users/bolsinga/Desktop/itunes-dst/pacific.db
6659|3222159084106405326|Walk On||Neil Young|Young, Neil|On the Beach||1|8|1|1|1974|161133|2025-02-12T17:37:09Z|0|Neil Young|1974-07-16T07:00:00Z||2025-02-12T17:40:51Z|1

2025-02-12T17:37:09Z is the correct time in UTC when it happened. It seems if the time zone (or daylight savings) changes, then it has an invalid value.

[bolsinga]

So maybe the initial value is correct, and then we ignore exactly 1 hour time stamp changes?

[bolsinga]

For the flat database, maybe add UNIQUE(itunesid, dateadded)? This is because the date added never changes.