prefer missing endDate over endDate in future

[crotwell]

Back in SEED days, the endDate for an active network/station/channel was set to something way out in the future, like 2500-01-01 to indicate it still exists. Since stationxml can have the endDate be optional, it is better to leave it out rather than put in a date in the future. Would be good to have a rule to flag endDates that are in the future to encourage the new style. I am not sure if warn or error is more appropriate.

It could be that temporary networks with known endings, legitimate stationxml could be created with endDates that are in the near future, so flagging any dates in the future may be too restrictive. But any date more than X years in the future could be flagged. Not sure if 10 years is too short?

Also, see this stationxml issue

[timronan]

EndDates > 2100 are a problem because some historical software are dependent upon them. At IRIS DMC, we consider any endDate > 2100 as an open, continuous, experiment. We use 2100 because there should be a large cushion of time to allow temporary expirments to operate. Saying this, we have been making an effort to change EndDates > 2100 to null.

Catching metadata that contains endTimes>2100 is a piece of the puzzle that we were recently considering. The validator may or may not be a good place to address this issue, but this is a good purposed rule.

The rule would read:

Network:endDate must be assigned < 2100-01-01T00:00:00 or NULL and
Station:endDate must be assigned < 2100-01-01T00:00:00 or NULL and
Channel:endDate must be assigned a date < 2100-01-01T00:00:00 or NULL

I think this would probably have to be a warning because their may be a use case to have a temporary Network/Station/Channel with a very long epoch. Assigning an endDate is a good way to signal that an experiment is temporary.