aredington / monotony Goto Github PK

period-named? sounds like it compares against a string, but it actually compares against a key. Moreover, if you pass in a string, you get a NullPointerException.

The concept of a "named" period is a bit deceiving, because all you do is compare the value of the field at the start and end times. For example:

(m/period-named? conf (first (m/periods conf :week)) :august)
;; true

I'm wondering if it's better to to offer something like:

(m/start-day-of-week conf period)
;; (.get (m/calendar conf (t/start period)) Calendar/DAY_OF_WEEK)
(= Calendar/SUNDAY (m/start-day-of-week conf period))
;; true

The thought would be to open up utility functions to go from periods to the calendar fields for the start and end instants.

What do you think?

The periods returned by monotony do not accurately reflect the TimeZone data of the config. Per #5, a config for New York (U.S. Eastern Time) returns instants that are in UTC. It should be returning instants that reflect the TimeZone data of the config.

Hello Alex,

Have you considered inclusive and exclusive boundaries to capture the time outside the 1-second quantization?

An example is the PostgreSQL Temporal Extension period type:

                     period                      
   --------------------------------------------------
     [2011-01-01 00:00:00-08, 2012-01-01 00:00:00-08)

This particular text representation is not appropriate for lisp, but the functionality seems like a good fit for monotony.

http://temporal.projects.postgresql.org/reference.html

Paraphrasing:

"The period text representation is one of the following forms:

  [ timestamptz, timestamptz )
  ( timestamptz, timestamptz ]
  [ timestamptz, timestamptz ]

"Where timestamptz is a valid representation of a timestamptz. The choice of brackets represents the inclusiveness of the interval. A square bracket makes that side inclusive, and a peren makes that side exclusive.

Thanks,
Jeff

Hi! Just watched your "lightning talk" from 2011 and my curiosity was piqued to see if your library does better than Rails' Active Support when it comes to doing arithmetic on dates...

 (import 'java.util.Calendar 'java.util.TimeZone)
 (def tz (TimeZone/getTimeZone "America/New_York"))
 (def cal (m/local-cal))
 (.setTimeZone cal tz)
 (.set cal Calendar/MONTH 10)
 (.set cal Calendar/DATE 1)
 ; DST ends on Nov 3 in EST...
 (def config {:calendar (fn [] cal) :seed (fn [] (.getTimeInMillis cal))})
 ; get the period spanning the DST change...
 (last (take 3 (m/periods conf :day)))
 => [#inst "2013-11-03T04:00:00.000-00:00" #inst "2013-11-04T04:59:59.999-00:00"]

You can see here that currently, Monotony incorrectly defines a "day" as a fixed 24 hours. Depending on where you are, a "day" can be 23 or 25 hours when going in or out of DST.

The way Rails handles all such cases really bugs me: when you are adding time intervals, it converts the interval down to an offset in seconds, then blindly adds that number of seconds without considering leap years, differences in the length of the different months, etc. Monotony has the right idea when it comes to years and months; it would be nice to handle hours/days correctly as well.

As an aside, thanks for making this library available!