All you are doing with an ORM is mapping entities to POJOs. If you have an entity which defines a date as three fields, rather than using a DATE or TIMESTAMP (I can think of no good reason for doing this, but I'll assume you have one) then these values just get mapped to properties in a POJO. So rather than concatinating them in SQL, I'd include a derived property in your POJO which is these three properties concatinated.
Should I bother learning HQL? I'm comfortable with SQL already.
Its a good idea. Remember that SQL isn't truely portable. It might be called a standard, but its been variously implemented and extended on different DB platforms. The digits function you are using here for example isn't SQL, its Transact SQL (correct me if I'm wrong - I haven't checked).
One of the reasons for using an ORM is to free yourself up from DB dependencies - unfortunately if you rely on SQL rather then HQL you'll have to be very careful you don't introduce code which will generate SQLExceptions when you deploy it with a DB platform other than the one you developed on. And HQL is not exactly complicated anyway.
That's a good reason to larn HQL. Our backend is currently DB2 on AS400, but will be moving to Oracle in the next few years. When the change happens, all I would have to do is change my dialect setting, right?
FYI - I curse the designers of this DB every day. There is no good reason for the split dates, AFAIK.