Suggestion: it is quite easy to mess up timestamp formatting upon conversion from OffsetDateTime into a string. Whereas #170 was an one-shot fix for all POST requests, which benefit from implicit Object-to-String conversion via convertToString, keep in mind that GET request params must be serialized by clients (cf. Map type parameters in getparams versus postparams in makeApiCall). Therefore, whenever client code forgets to truncate timestamps prior to converting them into strings, underlying makeApiCall calls might return a badtimestamp error. I observed that OffsetDateTime instances may produce different strings on different machines: my application ran fine on WMF servers, but crashed because of this issue on my local PC.
To sum up: perhaps the Map<String, String> getparams stuff could be refurbished into a Map<String, Object> getparamsand take advantage of convertToString as well?
This is a follow-up to https://github.com/MER-C/wiki-java/issues/170. I found a few more places where truncation is necessary, otherwise MW serves
badtimestamperrors.Suggestion: it is quite easy to mess up timestamp formatting upon conversion from
OffsetDateTimeinto a string. Whereas #170 was an one-shot fix for all POST requests, which benefit from implicit Object-to-String conversion viaconvertToString, keep in mind that GET request params must be serialized by clients (cf.Maptype parameters ingetparamsversuspostparamsinmakeApiCall). Therefore, whenever client code forgets to truncate timestamps prior to converting them into strings, underlyingmakeApiCallcalls might return abadtimestamperror. I observed thatOffsetDateTimeinstances may produce different strings on different machines: my application ran fine on WMF servers, but crashed because of this issue on my local PC.To sum up: perhaps the
Map<String, String> getparamsstuff could be refurbished into aMap<String, Object> getparamsand take advantage ofconvertToStringas well?Also, consider refactorization of:
A protected method could be useful for derived classes.