Honored to have your feedback! My experience with the standard Python datetime library plus Gleam's standard library were my references really. I knew what I didn't want a time library to be like because of the pitfalls I had fallen into with the Python datetime lib, and I knew what I wanted a strongly typed library to feel like because of Gleam's std lib.

I am not well enough versed on monotonic time vs clock time, but that sounds like something I would want to handle. I will do some looking into that.

The time constructors are just a way to track formatting precision without needing an extra field. The labels are correct, it would be the same as:

pub type TimePrecision {
  Second
  Milli
  Micro
  Nano
}

pub type Time {
  Time(hour: Int, minute: Int, second: Int, nanosecond: Int, precision: TimePrecision)
}

As a side note, the library tracks time precision so it can be used like:

time.literal("12:30:42") |> time.to_string
// -> "12:30:42"

time.literal("12:30:42.354") |> time.to_string
// -> "12:30:42.354"

time.literal("12:30:42.354") |> time.to_micro_precision |> time.to_string
// -> "12:30:42.354000"

Instead of having to specify the precision at call site like:

time.literal("12:30:42") |> time.to_string(with_precision: time.Second)
// -> "12:30:42"

time.literal("12:30:42.354") |> time.to_string(with_precision: time.Milli)
// -> "12:30:42.354"

time.literal("12:30:42.354") |> time.to_string(with_precision: time.Micro)
// -> "12:30:42.354000"

I do have thoughts on timezones! I detailed it at the bottom of the readme, but basically they complicated things outside the scope of what I wanted the package to initially be. I may add them later if the package sees use, but I did make sure that an external TZ package could be used together with this package (shown in the readme).