Reputation: 433
A client's API that I am integrating with returns a time with the time zone as a short id (3 letter id). e.g.
9:00 MST
13:30 EDT
17:00 MDT
I realize this is bad practice (especially with the daylight savings), and short ids should be avoided, but unfortunately I have no way to get the client to change their api. Is there a clean way to convert these short ids to a property ZoneId
? ZoneId.SHORT_IDS
looks like the closest, but it doesn't include daylights savings. Worst case, I think I can just make my own map of short ids to ZoneIds
since it's limited to the US
Upvotes: 3
Views: 789
Reputation: 338564
13:30 EDT
A time-of-day plus a time zone makes no sense. Without the context of a date, there is no real meaning here.
The SQL-92 standard declares a TIME WITH TIME ZONE
type, but neglects to define its meaning. I am not alone in being mystified by the SQL committee’s intention. And also, importantly, that data type is a misnomer: the SQL standard means offset when they say “time zone”.
Java offers an OffsetTime
class. I presume this class exists merely for mapping through JDBC to that screwy SQL type of TIME WITH TIME ZONE
. The Javadoc offers no real explanation as to the meaning of this class.
So what is your goal? I suggest you edit your Question to indicate what kind of processing you intend to do with such inputs. Perhaps we can guide you from there.
You asked:
Is there a clean way to convert these short ids to a property ZoneId?
No.
These 2-4 character pseudo time zones are not defined, are not standardized, and are not unique.
CST
— Do you mean Central Standard Time in the Americas? Or do you mean China Standard Time? Or Cuba Standard Time?IST
— Do you mean India Standard Time? Or Ireland Standard Time?PST
— Pacific Standard Time or Pitcairn Standard Time?BST
— Bangladesh Standard Time, Bougainville Standard Time, or British Summer Time?AMST
— Amazon Summer Time or Armenia Summer Time?So, no you cannot cleanly determine a time zone from a pseudo zone. You can only guess. If you know for certain the domain of possible values you expect to receive, and you are certain as to their intended actual time zone, then you can create your own mapping.
But even then, there is no class in Java nor data type in SQL to represent a date with time zone. You would have to convert that time zone to an offset from UTC. And for that conversion, you would need a date to determine a moment to determine the offset in use at that moment by the people of that zone… which leads us back in a circle to point at the top of this Answer: A time with only a zone (or offset), but without the context of a date, makes no sense.
You said:
but unfortunately I have no way to get the client to change their api
Providing a time-of-day with an ambiguous pseudo time zone is like providing a money amount tagged with "dollar" while asking to convert to "francs".
franc
means the franc CFA in West Africa, the Swiss franc, or some other currency with that name.So what would you do with such a request? What can you do? You would have to either ask for much more explicit definitions, or you would have to refuse the request.
Upvotes: 4