Why use StringBuffer instead of StringBuilder? about zmanim HOT 5 OPEN

@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.

from zmanim.

@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.

from zmanim.

So java.util.Calendar?

from zmanim.

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 .

from zmanim.