Comment by RegW | Hacker News Reader

Comment by RegW | Hacker News Reader

For many years my advice to other java devs has been to avoid using java.util.Date and Oracle date columns where possible - for all the reasons given in the article, but generally because they don't always do what you expect.

The reason is that these dates encapsulates one concept of date (a point in time), and devs often try to use it for another (the legal date).

A legal date is fixed. It also has no time zone, but in a different way - it will not look different when viewed from another timezone. I was born on the opposite side of the world to where I live. The DOB on my passport didn't change, as I moved around the world.

Too often the user inputs a legal date. Software translates this to a point in time so it can be stored in one of these dates, the TZ info is lost, and before you know it the software is displaying a date other than that input. A bug is filed, a dev investigates and hacks code to add one hour, the bug is closed, and another opened when we pass into daylight saving.

It doesn't have to be like this - even MS Excel knows to just use a day count.

I am not using Java but I am right now making a booking system. I am storing local time (with Offset) and the timezone identifier such as "Europe/London".

How does using Day Count help?

Sorry for being oblique.

A day count is just the number of days since some arbitary point. Say today is 42849, tomorrow is 42850, etc.. If the user enters the 24th April 2017, you store 42849. When you read it back 42849 is always displayed as 24th April 2017.

There is no magic - you could just store 3 integers, or a formatted string say "20170424". Anything that doesn't involve timezones.

Perhaps, with your programming language you don't get the same issues, but to use java.util.Date you have to parse this into a number of milliseconds since 1 Jan 1970. You might round it down to midnight at the start of the day - or the end. You might select midnight according to local time (with or without daylight saving), you might use UTC, or you might unwittingly leave it to the machine. To persist this to a DB you might use some ORM mapping like Hibernate - which without careful configuration may also make some assumptions about timezone, and Oracle might do the same. By the time the value is read back, your date may not be the same one entered - and this may not show up until you pass into daylight saving.

Not at all, I was genuinely curious. Thanks for the detailed response, I understand what you were getting at.

Reply on news.ycombinator.com