Why lineups and timestamps decide the dataset
Nightlife data looks like ordinary event data and behaves differently in two specific ways, and both of them are decided at collection time rather than fixable afterwards.
The lineup is the first. An artist booking dataset - who plays which venues, in which cities, how often, and with whom - is the reason most clients come to this kind of source, and it exists only if artists were extracted as separate rows linked to events. Recovered later from a text field, artist names are ambiguous, collapsed with b2b billings and missing the ones written differently on different nights.
The timestamp is the second. An event starting at one in the morning belongs to the night before in how people talk about it and to the following day in how a computer sorts it. Both representations are needed and only one of them is printed on the page, so the other has to be derived while the context is still there.
The third reason is ticket tiers. Nightlife pricing moves in steps - early release sells out, advance opens, door price applies - and each step is a different price for the same night. A single price column records whichever step happened to be live when the crawler ran.
The fourth is that this is a regional source, strong in southern Europe and thin elsewhere. It is an excellent window onto Spanish, Italian and Portuguese nightlife and a poor one onto anywhere else, and we scope it that way.