DateAssert should not have static field

[assertj]

DateAssert should not have static field

[joel-costigliola]

I agree on the consequences but without dateFormat static field users would have to set the date format each time they call assertThat(), with static fields dateFormat can be set only once.

Do you think of a solution that would both simple for users and parallel safe ?

[ash2k]

I think it is possible to use ThreadLocal to avoid sharing instances between threads. That way it would be possible to set required format in @Before/@BeforeMethod-annotated methods for the current thread.

p.s. also I think it's worth mentioning in JavaDoc that with default format current timezone is used i.e. of the machine where tests are executed. This can cause problems.

[kretes]

I would say keeping any state between two assertions is a premature optimization.

I understand the problem to be solved was to replace:
assertThat(date).withFormat(dateFormat).isAfter(dateAsString)
assertThat(date).withFormat(dateFormat).isAfter(dateAsString)
assertThat(date).withFormat(dateFormat).isAfter(dateAsString)

with
DateAssert.setDateFormat(dateFormat);
assertThat(date).isAfter(dateAsString)
assertThat(date).isAfter(dateAsString)
assertThat(date).isAfter(dateAsString)

but user could really easily do it with wrapping the assertThat(date).withFormat(dateFormat) in some private method.
I will try to make it ThreadLocal, though, but I would vote for changing it to assertion instance, starting with marking methods as deprecated

[joel-costigliola]

I'm thinking that it might be better to take another approach similar to the way we deal with date default formats.

Instead of replacing the custom date format, we could just add it to a list of custom date formats, this should fix the problem described if code accessing custom date formats list is properly synchronized or if we use a concurrent collection (CopyOnWriteArrayList ?)