Alejandro Colomar wrote: > However, I'd say that's more likely to be that the authors of RFC 9557 > didn't think of dates without time (maybe they didn't think of a case > where this would be useful), rather than having expressely desired to > not include it in their standard. And so, let's say this is a tasteful > extension to RFC 9557. :)
Dates without times open another can of worms. It starts with the question "What is a day?". If a programmer answers it with "A day is a 24-hours period", they already lost, because there will be bugs across the entire DST period of the year. A more intelligent programmer will answer it with "A day is a period of 23 or 24 or 25 hours, going from 00:00 to 24:00 of each date", and represent it through the 00:00 time point of the date. This programmer nearly has it right. But when they compute, say, <day> 08:00 = <date> + 8 hours, they are lost as well, because there will be bugs on the days where DST starts or ends. An adequate answer is a period of 23/24/25 hours, represented through the 12:00 time point of the date. For business purposes (say, work hours from 08:00 to 17:00), the time points get computed correctly. However, care must be taken in various conversion functions, that the 11/12/13 hours offset gets taken into account. The best answer is probably an interval with two time points (<day> 00:00 and <day+1> 00:00). But programmers dislike that computations take twice as much time as "necessary". In summary, I think dates without times were wisely excluded from RFC 9557. Bruno
