all things in musicbrainz has a “life-span” and that life span had 3 fields.
a begin, and end and a checkbox if it is ended (this is mainly used if you know that it is ended but you don’t know when it ended).
the ended checkbox get automagically checked when you enter an end date.
this is all good and well for artists and stuff since the end mostly represents a death or a split from the band. and this can mostly only be but in the database after the fact. (its difficult to predict the future)
but in events you can create stuff that will be happen in the future. (a gig that is next month)
the life span is more a representation of the length. if it is an event that only happens on one day the begin & end are the same date.
but because the end is filled in, the ended checkbox is checked.
but stuff that is in the future haven’t ended yet. they haven’t started yet, so how can they be ended?
the reason i bring this up is i’m looking for a more efficient way get all the events of an area that have not ended yet. (as in they are in the future)
currenlty i do a browse of ALL the events in that area and then once i have al the events i check the date and throw away everything that is in the past.
If you are uncertain whether the event (for example, today is the 7th, and the event is scheduled for the 13th) will proceed as planned on the 13th or whether it will conclude on that day, you can choose to leave the end date blank.
This avoids providing potentially inaccurate information. You can even wait until after the event has actually concluded before adding the information to MB.
Are you trying to express that,
for example, if today is the 7th and you add an event with both the start and end dates set for the 13th, then the data should only show as “ended” once the actual date reaches the 13th, rather than immediately marking it as ended as soon as an end date is entered?
that’s not always true. if there is a 5 day event and we are at day 3 then the event isn’t in the past yet. it hasn’t ended yet. your more likely to ignore the begin date since it doesn’t matter when it begins. aslong as it hasn’t ended yet.
but again that is not really the problem. i actually need an extra parameter where i can filter on only events in the future.
with this: https://musicbrainz.org/ws/2/event?area=489ce91b-6658-3307-9877-795b68554c98&limit=100&offset=0&fmt=json
i get ALL the events in america. since there are 32302 events (currently) and i can only get a maximum of 100 events per request and i can only send 1 request per second. that wouuld meen that it would take 324 seconds (5.4 minutes)
after i waited almost 6 minutes i manually check which ones are in the future and wich ones are in the past. this would mean that almost 90% (i am just guestimating here) is not useable since i have no use for the events that are in the past for this application.
it would be more efficient if i couuld add the future only parameter. in stead of having 32302 events i could get like 1000 events wich will only take 10 seconds. AND i don’t need to filter them afterwards.
i think this can be very usefull, if other websites want to use the musicbrainz data to promote events they want to promot the upcoming events, there is no business in promoting events that are in the past.
The attribute really indicates that something has an end. The point is that things can be known to end without knowing a date. In this case the end date will be ended, but the checkbox can still be set. If there is an end date explicitly set it is clear that thing does have an end and the checkbox is set.
The end date is still in the future then, that’s what jesus2099 was talking about.
I suspect that you may need to use the Search API for this (but note that it won’t include as much information as browse requests, e.g. setlists aren’t included).
