Why use StringBuffer instead of StringBuilder?
Opened this issue · 5 comments
The javadoc for it says
As of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization.
@Sternbach-Software , This is a fair question and I will change it. The reason it uses StringBuffer is because the code dates back to 2004 before the Sept 2004 release of Java 5. At this point there is no reason not to change it.
@Sternbach-Software,
While this request is trivial, I realized when looking at this class that there is no TimeZone attached to this. While the moment in time will be fine, a typical use-case will require a time zone. This requires a drop more of a change than just changing a StringBuffer to StringBuilder.
So java.util.Calendar?
Then again, what are the use cases? Maybe the most common use case is calculating a zman for a given time zone, wrapping it in a zman, and displaying it to the user. My implementation of Zman uses kotlinx.datetime.Instant which forces you to provide a timezone when you want to convert it to a LocalDateTime and when creating the Instant, but that would be the responsibility of the accessor of the Instant when they want to do that date math or conversion. Maybe it should be the same thing here? Provide them with the minimal necessary information that they couldn't easily get without rewriting the library, and let them use that to do what they need. Still not sure what use cases you intended this for. I use this to solve #217 .
Fixed in via 8a643bc.
Thanks @Sternbach-Software