haha having had to deal with developer glazeover from DST implications before I suspect we’re not alone. One may accept the inevitable failures that are implici

haha having had to deal with developer glazeover from DST implications before I suspect we’re not alone. One may accept the inevitable failures that are implicit with the naive date time representation and possibly get a MVP going, but it’s not really more expensive/time consuming to kick the can down the road and hide the inevitable failures behind an interface. The latter requires you to be explicit about the functionality you expect from a date/time value. This means you need a[0] a way to distinguish the type of value it is by the ways you expect to use it... In data modeling I hide such things behind a foreign key to create a distinct domain. E.g. “PersonBirthDate”, “StartedAt”, “ValidAfter”, “AvailabilityInterval", “FiscalQuarter”, and “ExpiresBy” are all different representations, possibly also distinct by the source entity, and all treated as a distinct domain. Further I’ll often add UDTs and database functions/procedures to help assure integrity (and possibly quality, not always possible of course). Sum Types are unpleasant to model in RDBMS and descendants of such. [0] a pun, HHOS. <https://en.wikipedia.org/wiki/Yoneda_lemma https://en.wikipedia.org/wiki/Yoneda_lemma>