Closed andyatterton closed 11 months ago
I'm sure that is correct but more generally why are the databases set up with the dates as datetimes. I can see this as being a problem when you do date1==date2 and the clocks have changed or something.
Because sometimes the time is important. Bad idea for dates of birth (unless you really want to know birth time) but for transplants that could have more than one occurrence in a single day the time is relevant.
Pretty sure datetime handles daylight savings with timedeltas + 1hour
Edit: also if you are comparing two dates that you are expecting to be the same then surely they would have both occurred in the same daylight savings scenario. date1==date2 will be true if they are the same time and false if not, don't see how daylight savings come into it
Mmmm yeah I understand that datetimes are appropriate in circumstances where the time is important but it seems like it adds an additional potential source of error if not.
I wouldn't personally of used date times for most of it, especially considering this is being delivered via CSV and doesn't come with any time stamps, but I suppose in a world where we might one day receive date times through an automatic feed it could be considered future proofing
Some of the field choices in the "renalreg" database are explained by the structure having been a conversion of the preceeding Oracle database - if the date/datetime fields aren't what one might have chosen you should see how the numeric values are being stored.
All of the columns recording dates were of type date and should be datetime to accuratly mirror the database. Also changed the bit column to a boolean as I believe this to be the correct way to map that column type.