Fork me on GitHub
#juxt
<
2016-11-12
>
niwinz01:11:24

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

niwinz01:11:37

or miliseconds from the epoch 馃槃

malcolmsparks10:11:49

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

imre10:11:48

Thanks guys

imre10:11:22

These can be good when I want to store instants

imre10:11:38

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

imre10:11:06

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

imre10:11:16

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

niwinz10:11:32

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

niwinz10:11:46

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

niwinz10:11:43

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

imre15:11:49

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

imre15:11:35

My experience is almost exactly the opposite

imre15:11:43

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

imre15:11:00

Or when talking about time-of-the-day

imre15:11:46

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

imre15:11:37

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

imre15:11:26

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

niwinz17:11:17

is a good article that explains that

niwinz17:11:36

this is postgresql related but is pretty interesant to read

niwinz17:11:05

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