Rarity uses hardcoded texture names to detect which holiday is currently active. There are now several issues:

• The API used no longer returns texture names, but rather these fileDataIDs
• Additionally, there are multiple textures that vary by faction and whether the event starts, ends, or is ongoing
• Since events may end in the middle of any given day, the detection would likely fail in this fringe case (semi-related issue)
• And as a side note, the holiday detection logic is deeply embedded in the UI code (that should be fixed independently)

I'm not sure if there are any holiday events that don't start or end at midnight. If so, they're probably going to be missed. As it stands, even those events that do start/end at midnight are no longer being detected, which means Rarity shows all those holiday items as "unavailable". The issue with multiple textures being required would necessitate some more complex logic.

The simplest solution is likely a many-to-one lookup table: All "new" DMF textures are checked against the item's setting, and if any of them matches the item should be considered "available". This means none of the actual database entries need to be changed, although the texture ID field name is somewhat misleading and should likely be renamed to requiredholidayEvent (or similar).

Still TBD:

• Will renaming the field cause any issues with custom items? -> Nope, they can't use the field AFAICT.
  • If yes, that would be problematic (breaks backward compatibility). How problematic, though?
• What other changes in the addon core are needed to be able to rename the field?
• Is there a way to easily test this without waiting for an actual holiday event? I've one idea but it isn't clean...