BZLIB/DATE & BZLIB/DATE-TZ 0.2 Now Available

bzlib/date and bzlib/date-tz are now available via planet. They are released under LGPL. You can find the previous documentation for previous usage.

The changes included are:

• re-exports for SRFI-19 functions
• Wrapper functions for PLT date objects (you can use the functions with PLT date objects instead of with SRFI date objects)
• day comparison functions
• RFC822 date parsers and generators
• additional date manipulation functions

SRFI19 Re-export
Previous you have to explicitly include srfi/19 to use the functions within SRFI19 as follows:

(require srfi/19 (planet bzlib/date)) 

Now you just have to do the following:

(require (planet bzlib/date/srfi)) 

And almost all srfi/19 functions will be re-exported along with the functions within bzlib/date.

The exceptions are date->string and string->date, neither of which are exported from srfi/19. This is because we may want to use those names for our own date parsers and generator functions. I'll examine the details before deciding whether to re-export those or create our own.

PLT Date Wrappers

You now can use PLT date objects instead of srfi/19 date objects (I do not really know why they are different date objects in the first place...). You can just do the following:

(require (planet bzlib/date/plt)) 

Which will export functions with the same name, but takes (and returns) PLT date objects instead of SRFI date objects. Because the exports are the same name - you cannot require it along with the SRFI-date version.

Besides wrapper over all of the bzlib/date functions, it also wraps over the srfi/19 functions, so you can use, for example, current-date and it'll now return a PLT date object.

This version also does not export string->date and date->string.

bzlib/date-tz also exports its functions in PLT wrapper form:

(require (planet bzlib/date-tz/plt)) 

It does not re-export bzlib/date/plt so you will need to explicitly require it if you want to use its functions.

There is a matching module in bzlib/date-tz/srfi but it is exactly the same as bzlib/date-tz. This is provided so you might write mirroring code:

;; in one file... 
(require (planet bzlib/date/srfi)
         (planet bzlib/date-tz/srfi)) 

;; then you can change it to 
(require (planet bzlib/date/plt)
         (planet bzlib/date-tz/plt)) 

Different Types of Date Comparisons

The date comparison functions (date=?, date<?, date>?, date<=?, date>=?, date!=?) can now be used to compare the dates in the following fashions:

• You can now compare multiple dates at once (previously - just two)
• You can use it to compare for:
  
  • day-only - just compare the day (year month and day)
  • day+time - compare both the day & the time (hour minute second), but without comparing timezone
  • date - this is the default behavior - compare the date & time as well as accounting for the timezone.
  • date+tz - this would require the dates being compared all have the same time zone

To control the behavior, you use the date-comp-type parameter:

(parameterize ((date-comp-type 'day-only ;; or 'day+time 'date 'date+tz 
                ))
  (date<? d1 d2 d3 ...)) 

day=?, day!=?, day<?, day<=?, day>?, day>=? are provided as helper functions that parameterize the date-comp-type to 'day-only for you.

Additional Utility Functions for Timezone

current-date/tz returns a date based on the optional tz value (which defaults to (current-tz):

> (list (parameterize ((current-tz "America/Los_Angeles"))
          (current-date/tz))
        (parameterize ((current-tz "Europe/Brussels"))
          (current-date/tz)))
;; notice the date difference... 
(#(struct:tm:date 0 56 18 13 20 10 2009 -25200)
 #(struct:tm:date 0 56 18 22 20 10 2009 7200))

daylight-saving-time? returns true or false depending on the optional date and tz (default to the current-date & current-tz):

> (list (parameterize ((current-tz "America/Los_Angeles"))
          (daylight-saving-time?))
        (parameterize ((current-tz "Asia/Taipei"))
          (daylight-saving-time?)))
(#t #f)

That's it for now. Enjoy.