hello. firstly, this isnt a tick issue - but a java.time one. and it does trip people up... so much so that it is only one of 3 top tips in the readme: https://github.com/juxt/tick?tab=readme-ov-file#instants.

It's explained in the readme What Henry said https://github.com/juxt/tick#instants the library is an abstraction over java.time. I would definitely recommend reading the relevant java docs, the whole tick api made so much more sense to me after that. https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/time/format/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/time/temporal/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/time/zone/package-summary.html and the tutorial is linked in the tick docs https://docs.oracle.com/javase/tutorial/datetime/iso/overview.html

I see

t/zone of instant is hard coded to "UTC". I my case I expected it to use that when going from instant to local-date instead of (current-zone) but I guess that is highly subjective and dependent on the problem. I would argue though that it's less of an issue in java.time because it doesn't allow you to go from Instant to LocalDate without explicitly passing a Zone.

Thank you for your answers and the links, I will study the the java.time API documentation some more!

yeah true. I think if doing it over I would probably not have anything using current-zone - but it has been like that since the start of tick and too late to change now

It’s definitely a source of side effects that I didn’t think about until now 😄

well yeah the ambient clock , providing both the now and where info, in use for example when you call (t/date)and so on is hardly textbook functional programming.