I just had a look, just to be sure it's not related to recent changes in this area, and it doesn't seem so:

1. This bug occurs at least as far back as in 5.3.2.Final
2. This bug only occurs when using the datetimeoffset column type; datetime2, the default when Hibernate ORM generates the schema, works fine. I'm not sure we ever tested this.

What I could see:

• The test stores 1969-12-31T19:00-05:00 in the entity
• org.hibernate.type.descriptor.java.OffsetDateTimeJavaDescriptor#unwrap receives 1969-12-31T19:00-05:00 from the entity (all good)
• The method returns a timestamp whose number of milliseconds since the epoch is 0, and displayed as 1970-01-01 01:00:00.0 (still good, since that's the correct time in the default JVM timezone)
• This timestamp gets passed to the JDBC driver (a SQLServerPreparedStatement)
• The JDBC driver stores 1970-01-01 01:00:00.0000000 +00:00 (WRONG)

I believe the problem is in the way the MSSQL JDBC driver interprets the Timestamp. If you really want to use dateoffset, maybe you should look at how this JDBC driver works?