The information content of a TIMESTAMP WITH LOCAL TIME ZONE value is just a 64 bit integer, no time zone. So it doesn't seem right that the TimeWithLocalTimeZoneString has a time zone inside it. We are on shaky ground if the literal has more information content than the runtime value.
This change adds a new data type, and we ought to nail down the semantics, which would include tests of various queries and also tests for JDBC driver support. I think it is unreasonable for me to expect all of that, but the time zone field in TimeWithLocalTimeZoneString needs to go, otherwise we will be tempted to give this the same semantics as TIMESTAMP WITH TIME ZONE, which it emphatically does not.
Can you also update reference.md with the new data types.
In Hive (and the semantics I assume you are trying to achieve here), is the time zone offset applied when the query is parsed, or when it is executed? I would assume parse time. If so, if I, in PST, parse a query with TIMESTAMP WITH LOCAL TIME ZONE '1970-01-01 08:00:00', I would expect it to create a TimestampWithLocalTimeZone(0L).
Also, if I create TimestampWithLocalTimeZoneString("1970-01-01 08:00:00", "PST") and TimestampWithLocalTimeZoneString("1970-01-01 05:00:00", "EST") these values are equal, and have identical values in their internal fields. Their value is the epoch - either 0L or "1970-01-01 00:00:00", I don't care how you represent it internally.