For reading csv in java you could use libraries like e.g. this one.
As for the question in which attribute/object the parsed date should end up
"so my java object field must be of type : ZonedDateTime ?"
No, you could use a string, split it in several Integers, use DateTime plus a String for the time zone ... as you like it.
As for your pattern, check out the oracle documentation on datetimeformatter patterns, you can use this:
DateTimeFormatter f = DateTimeFormatter.ofPattern( "yyyy-MM-dd HH:mm:ss z");
System.out.println(ZonedDateTime.parse("2016-06-28 14:18:28 ADT", f));
says "2016-06-28T14:18:28-03:00[SystemV/AST4ADT]"
where "SystemV/AST4ADT" on one side shows up in respectable lists but on the other side seems to be an outdated convention (from SystemV).
Now in comments it has been noted that the same input string on other systems yields
2016-06-28T14:18:28-03:00[America/Halifax]
and I think, that can be traced back to the setup of your local system, more precisely, the jvm time zone settings and the local time zone of your machine (see below).
Considering the additional info from the comments it becomes clear, that you can't realiably recover "ADT" (literally) from your input string, taking the route over ZonedDateTime. If you want to retain it, something like "2016-06-28 14:18:28 ADT".substring(21)
might be the most economical version, ugly as it is. I'd take it.
There are alternatives, though. Chances are, all your date values stem from the same time zone anyway and you don't need it in the first place. If you do, you could create a mapping between all possible time zones, 425 at the moment, to their abbreviations (zonedDateTime.getZone()->String).
Now it's getting really esoteric, there appears to be a mysterious time zone updater tool by Oracle, which is supposed to keep JVM's time zones up to date and which takes it's values from a time zone database, the currently maintained version is IANA's Time Zone Database, when downloaded it contains an theory.html
with a section "Time zone abbreviations" which says: "When this package is installed, it generates time zone abbreviations like 'EST' to be compatible with human tradition and POSIX". Then I discovered to my delight that on linux there's the zdump command which responds to zdump Canada/Atlantic UTC
with
Canada/Atlantic Sat Oct 12 03:39:19 2019 ADT
You can extract the whole list, I put the command and the output in a github gist. What you don't get is a decoding for e.g "SystemV/AST4ADT". The whole SystemV nomenclature seems to be deprecated, so I wonder, how this pops up in ZonedDateTime. Where I eventually found it was the "systemv" file in ican's database, you can find the relevant content below.
There's also a web service provider out there where you can find a hopefully complete list of time zones plus abbreviations and you could probably use the service, if you're into this kind of thing. Doesn't account for stuff like "SystemV/AST4ADT", though.
Content of "systemv" file, you'd have to map to the Time Zone Database abbreviations using the GMT-offsets (like -4:00)
tzdb data for System V rules (this file is obsolete)
Zone NAME STDOFF RULES/SAVE FORMAT [UNTIL]
Zone SystemV/AST4ADT -4:00 SystemV A%sT
Zone SystemV/EST5EDT -5:00 SystemV E%sT
Zone SystemV/CST6CDT -6:00 SystemV C%sT
Zone SystemV/MST7MDT -7:00 SystemV M%sT
Zone SystemV/PST8PDT -8:00 SystemV P%sT
Zone SystemV/YST9YDT -9:00 SystemV Y%sT
Zone SystemV/AST4 -4:00 - AST
Zone SystemV/EST5 -5:00 - EST
Zone SystemV/CST6 -6:00 - CST
Zone SystemV/MST7 -7:00 - MST
Zone SystemV/PST8 -8:00 - PST
Zone SystemV/YST9 -9:00 - YST
Zone SystemV/HST10 -10:00 - HST