POC end datetime

[VIKTORVAV99]

Description

Already had some quick changes for ENTSO-E production so I could determine the scope of this.

Figured I might as well put it here for you guys to have a look at.

Output would be:

    dict({
      'correctedModes': list([
      ]),
      'datetime': datetime.datetime(2025, 10, 21, 16, 45, tzinfo=datetime.timezone.utc),
      'datetime_end': datetime.datetime(2025, 10, 21, 17, 0, tzinfo=datetime.timezone.utc),
      'production': dict({
        'biomass': 774.79,
        'coal': 129.6,
        'gas': 14.7,
        'hydro': 1236.7,
        'nuclear': 4175.4,
        'oil': 0.6,
        'solar': 1.8,
        'unknown': 144.6,
        'wind': 5821.4,
      }),
      'source': 'entsoe.eu',
      'sourceType': <EventSourceType.measured: 'measured'>,
      'storage': dict({
      }),
      'zoneKey': 'FI',
    }),

[seljaks]

High level it looks good!

Have a question about changing the dict key from datetime to tuple[datetime, datetime]. Is there any mechanism where we ensure that events can't be overlapping? Previously this was kinda implied because the next datetime was considered the end of the the currect datetime. Can we have a case now where we have an event with start=x, end=y and another with start=x, end=z i.e. we have two events that partially overlap?
I know this would get caught on DB ingestion because we're not changing the PK, but would be nice to ensure this on the parser side if possible.

[VIKTORVAV99]

I didn't implement it (yet) but that should be possible with the pydantic validators in the base parser classes. That particular change in the datetime to a tuple is just in the internal representation of the entsoe data in this specific parser. The output would be a plain dict/json where the key is called datetime_end(or what ever we pick).

Might be a better way to do it if we refractor it a bit but this was the quick and easy solution (and should work pretty good since we get the start and end at the same time).