Hi there!

Java Date are precise to milliseconds so I think it would be a good idea for this library to support milliseconds.

Otherwise, you don't have any way of creating two equal dates:

val date     = Dates.of(year = 2016, month = 2, day = 26, hour = 18, minute = 58, second = 31)
val sameDate = Dates.of(year = 2016, month = 2, day = 26, hour = 18, minute = 58, second = 31)
date.equals(sameDate) // => return false!

This PR allow this library to creates two equal dates:

val date     = Dates.of(year = 2016, month = 2, day = 26, hour = 18, minute = 58, second = 31, millisecond = 777)
val sameDate = Dates.of(year = 2016, month = 2, day = 26, hour = 18, minute = 58, second = 31, millisecond = 777)
date.equals(sameDate) // => return true

I think there is no breaking changes and all unit tests should pass. Don't hesitate to ask me for changes, I really like this library but I need to compare dates equality so I need this changes :)

Dates.now is expected to be the current time but instead it's the time that the application has started due to it being initialised as a static property. Shouldn't this return a new Date object every time it gets called?

Add support for setting milliseconds, as epoch time in Java based on millis and not on seconds.

@hotchemi The unit tests works on my machine, do you have any idea why they fail?

Due to the incorrect subtraction here the expression "1.month" returns a duration of 0 months. As a consequence, this obviously incorrect test passes: assertEquals(Dates.today, 1.month.ago)

import khronos.Dates.today
import khronos.day

fun main() {
	val d = 0.day.ago
	val n = today
	println(d)
	println(n)
	println(d > n)
	println(0.day.ago > today)
}

Mon Jan 06 14:29:48 MSK 2020
Mon Jan 06 14:29:48 MSK 2020
false
true // incorrect - expect `false`

Why 1.month is 0 based and is not consistent with other properties?

This very confusing when 1.month.ago == today

    val monthAgo = 1.month.ago.month
    val today = Dates.today.month
    assert(monthAgo == today)

#30

This is a breaking change, but it is an improvement in terms of semantics. We should not take the 0-index ordering of months of the Java Date APIs as gospel here. 5.months should actually give us 5 months worth of duration to add to a Date.

fun main() {
	val n = Dates.today
	println(n)
	println(n - 1.month)
	println(1.month.ago)
	println(n - 1.day)
	println(1.day.ago)
	println(1.week.ago)
}

output:

Mon Jan 06 14:13:28 MSK 2020
Mon Jan 06 14:13:28 MSK 2020 // expect December 2019
Mon Jan 06 14:13:29 MSK 2020 // expect December 2019
Sun Jan 05 14:13:28 MSK 2020
Sun Jan 05 14:13:29 MSK 2020
Sun Dec 30 14:13:29 MSK 2020

khronos version: 0.9.0 JVM: 1.8 Kotlin: 1.3.61

I found a small problem when I was comparing dates.

After some debugging I noticed that you used Date.with(...) where we added all date properties except MILLISECOND.

fun Date.with(year: Int = -1, month: Int = -1, day: Int = -1, hour: Int = -1, minute: Int = -1, second: Int = -1): Date {
    calendar.time = this
    if (year > -1) calendar.set(Calendar.YEAR, year)
    if (month > 0) calendar.set(Calendar.MONTH, month - 1)
    if (day > 0) calendar.set(Calendar.DATE, day)
    if (hour > -1) calendar.set(Calendar.HOUR_OF_DAY, hour)
    if (minute > -1) calendar.set(Calendar.MINUTE, minute)
    if (second > -1) calendar.set(Calendar.SECOND, second)

    // NOTE : Added the next line. Used for compare
    calendar.set(Calendar.MILLISECOND, 0)

    return calendar.time
}

Problem is solved by adding the next line: calendar.set(Calendar.MILLISECOND, 0)

This might vary for every person. You could also add it as a parameter.

Day of month in Javas calendar starts with 1 not with 0. So the day -1 in Dates.kt is wrong.

As there is also a Test it might be intended. But I think it is misleading to write Dates.of(day=21) and expect the calendar date to be 20.

I like your library and it's very readable and use to fun. One thing I am wondering is if there is any multi-thread issue because your implementation has one instance.

internal val calendar: Calendar by lazy { Calendar.getInstance(DateHelper.getSydneyTimeZone()) }

From my understanding, lazy it doesn't create more than one instance and when thread1 and thread2 tries to update date, it think there could be a race condition. What do you think?

30.days.ago.beginningOfDay.time

The values are off by a few millis.

1508437800629 1508437800649

However Dates.today.endOfDay.time returns the same value for every invocation.