As Avi points out on the github issue discussion, this change would best be done throughout, i.e. wherever a DateTime instance is created, otherwise one would end up with surprising behaviour (default of UTC in date-time, default of JVM default time zone in formatter).
That being said, I would argue for keeping UTC as the time zone when creating DateTime instances (including via formatter), unless another time zone is explicitly requested. Although I appreciate the argument for following Joda time in using the JVM default time zone, I think clj-time would benefit from imposing a bit of purity in this case. Using the JVM defaults for such settings always allows some unpredictability to leak into your code (default file encoding, anyone?). In other words, the value of (date-time 1970 1 1) should not, in my opinion, depend on whether it is run on my machine or yours. clj-time.core makes it's use of UTC clear in the documentation, although a heads-up regarding the departure from Joda time's behaviour in this regard would probably help prevent users tripping over the same issue Avi had. On the other hand, I sympathize with Avi that it can be somewhat inconvenient to specify times in non-UTC. from-time-zone and to-time-zone are not the most succinct way of dealing with this, in my opinion. I admit I quickly ended up writing a helper function to produce DateTime instances for explicitly named time zones. Ideally I would like to be able to pass the time zone to date-time et al. The way date-time uses multiple arities currently precludes this, but my preferred way would be to say, e.g. (date-time :utc 1970 1 1 10 30) => #<DateTime 1970-01-01T10:30:00.000Z> or: (date-time :europe-barcelona 1970 1 1 10 30) => #<DateTime 1970-01-01T10:30:00.000+01:00> or indeed: (date-time (default-time-zone) 1970 1 1 10 30) => #<DateTime 1970-01-01T10:30:00.000+01:00> ; YMMV and to have UTC as a fallback when no time zone is specified: (date-time 1970 1 1 10 30) => #<DateTime 1970-01-01T10:30:00.000Z> I personally think it is helpful to make the time zone explicit by either passing it or accecpting the constant default of UTC. Dealing with dates and time zones is a lot like dealing with bytes and encodings. While cultural, operating system or run time defaults may lull you into treating the time zone/encoding as somehow supplementary and non-essential, you don't really know the value unless you define both aspects of the data (and you will get bitten sooner or later). Ok, I'll stop before I go completely OT. Regards, Caspar -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
