Clojurians Log v2

You also has the option to conver it to long as unix timestamp

or miliseconds from the epoch 😄

@imre you can convert between java.util.Date and java.time.Instant with .toInstant - doesn't that help?

Thanks guys

These can be good when I want to store instants

My problem is with cases when I want to store data that is not an instant, for example a LocalDate, YearMonth or LocalTime etc.

Or even a ZonedDateTime - Date doesn't have tz info

Usually when I talk about dates, I use LocalDate - that has just the right amount and precision I need, making compatison semantics unambiguous

In my opinion, when you are working with dates and persistence, you should work with instants plus a separate field for persist the timezone if it is needed. Later, when you should perform operations or just present that to the user, convert that instant to zoned date...

In almost all operations that you are going to do with dates, the correct way is doing them with instant, the timezone information is just a presentation property

doing operations with zoned date can cause unexpected situations and strange errors...

thanks for the insight @niwinz - are you aware of any resources where I could find more info about these problems you are referring to?

My experience is almost exactly the opposite

Date seems to be a decent representation of Instants but I found that when talking about dates (without the time part) it has too much info

Or when talking about time-of-the-day

As for zoned datetimes - in case the tz the information was recorded in is not important, Instant is perfect

but when TZ is important I like to keep it bundled otherwise it can get lost or ignored/forgotten to be taken into account

java.time seems to be an improvement over joda time and it seems to have very good semantics for temporal data of varying precision

@imre http://www.nurkiewicz.com/2016/08/guide-to-time-and-date-in-java.html

is a good article that explains that

http://phili.pe/posts/timestamps-and-time-zones-in-postgresql/

this is postgresql related but is pretty interesant to read

I was wrong only in one statement: many business logic can require work with ZonedDateTime and many other not. But the persistence and transmission is very recommended to just use Instant or unix epoch or datetime in utc (that in general view is equivalent to instant).