zmanim

zmanim copied to clipboard

java.util.Date has been deprecated for many years.

@pnemonic78 , the Date class was not deprecated. Many of its methods were, but not the Date class itself. It is more readable than using a long that would have to be described as a long starting at Jan 1, 1970 GMT :)

most Java developers already know that long time means milliseconds since 1970/1/1

most Java developers already know that long time means milliseconds since 1970/1/1

It still has almost no performance gain and has a small loss in clarity to developers. It would also break backwards comparability rather seriously. I am inclined to not accept this PR.

I know this would cause quite a bit of work on my part as a consumer of this library.

If such a change is needed, let's find a way to so in a backwards compatible fashion.

Thank you,

Jay

On Tue, Jun 21, 2022, 5:14 PM KosherJava @.***> wrote:

most Java developers already know that long time means milliseconds since 1970/1/1

It still has almost no performance gain and has a small loss in clarity to developers. It would also break backwards comparability rather seriously. I am inclined to not accept this PR.

— Reply to this email directly, view it on GitHub https://github.com/KosherJava/zmanim/pull/188#issuecomment-1162373465, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJHK2FSWEYTV3HL4KTVA43VQIWFFANCNFSM5ZJ4Z5EA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

@pnemonic78 and @jgindin , I am not sure that there would be value, but at some point (maybe v3.0.0) we may change Dates to the more modern java.time.Instant or a java.time.ZonedDateTime. ZonedDateTime would have an issue when dealing with times in the non "native" TimeZones, such as calculating UTC time globally (I know of concrete use cases for this). java.time.LocalDateTime and java.time.LocalTime are likely too ambiguous for us to use in this project.