You found the correct culprit, @jerome . It all goes back to the fact that the EPW format does not use “real” date/times and instead uses times like 24:00, which do not exist on any clock that I know of or in any datetime module of any major computer language. I think the number of 
on this Github issue to change E+ shows that I’m definitely not alone in expressing the headache that these datetimes have caused.
We struggled with a few different ways to work around this issue. In Legacy Ladybug, we tried following the EPW structure and made 1:00 the first time of the year (instead of 0:00) and we made the start hour-of-the-year (HOY) equal to 1 instead of 0. But we now see this as a mistake since it ultimately created several cases of mismatched datetimes across the plugin. So we knew that the start datetime definitely needed to be 0:00.
We could have just treated the EPW value at 1:00 as if it were at 0:00 but that would almost certainly result in mismatches between the imported EPW data and other timeseries data that might not originate from an EPW.
We looked at what E+ assumes and, given that every annual E+ run starts off with the simulation “warming up” by running through the first day of the year over and over until it converges, the value at 0:00 on Jan 1 is technically the value at 24:00 on Jan 1 (or I guess 0:00 on Jan 2?). We considered doing something like what E+ does but, then, that would result in a net loss of data because the value at Dec 31 24:00 of an imported EPW would effectively get deleted from the imported data collections upon import. So, when you went to write the imported EPW object back to a file, you would have replaced the real value that existed at Dec 31 24:00 (aka. 0:00 on Jan 1) with a duplicated value of whatever was at 24:00 on Jan 1 (aka. 0:00 on Jan 2).
So, ultimately, we just decided that “ladybug world” is separate from “epw file world”. In ladybug world, we use real datetimes and, whenever we import an EPW file, we perform the operation of moving the end value to the start to make things align with the datetimes. When we export the EPW object back to an .epw file, we put the start value back to the end. I know it can sometimes result in a jump between values for the first hour in the data collection but it’s really the only way that we could think of to “keep the worlds separate” and keep each world consistent with its own logic.
Could you describe further how this decision isn’t working out well for what you are trying to accomplish? Are you just questioning whether you should build an annual EPW by going from:
0:00 Jan 1, 2020 — 23:00 Dec 31, 2020
vs.
1:00 Jan 1, 2020 — 0:00 Jan 1, 2021
I’m sorry to say that, for reasons that were decided over 25 years ago when epw files were first made, it’s the latter. Welcome to our collective struggle with EPW datetimes!