Concernant la question 1 :fermé-ouvert est le moyen standard de gérer les plages de dates, avec 20 à 25 ans d'histoire dans la littérature académique. Voir pp. 24-25 de Données bitemporelles par Tom Johnston, et aussi Développer des applications de base de données orientées temps en SQL par Richard Snodgrass.
Mais je pense que l'une des raisons est que les plages consécutives ne se chevauchent pas. Si a est [May2016, Jun2016) et b est [Jun2016, Jul2016) , ils ne partagent aucun jour. Ainsi, ils "s'emboîtent" et vous n'avez pas à vous soucier des cas extrêmes où ils se touchent.
Notez qu'un inconvénient (peut-être) de fermé-ouvert est que vous ne pouvez pas spécifier une plage vide. [May2016, May2016) est simplement une contradiction, alors que [May2016, May2016] est un instant.
Concernant la question 2 :Encore une fois, cela aurait pu être différent, mais je peux penser à plusieurs avantages de rendre upper([May2016, Jun2016)) retour Jun2016 :
- Il renvoie la même chose quelle que soit la résolution de la plage.
- Cela ressemble plus à la signification mathématique d'un point de terminaison ouvert, où c'est le seul réponse possible.
- Il renvoie ce qui correspond à "l'étiquette", donc c'est sans doute moins surprenant.
- Il vous permet de voir facilement si deux plages "se rencontrent" :
upper(a) = lower(b).
Notez également que dans Postgres tous les types de données liés au temps sont discrets. Il y avait une option pour compiler Postgres avec des horodatages flottants, mais elle est obsolète et je ne l'ai jamais rencontrée.
