SRFI-19 Time/Date conversions

Function: date->julian-day date

Function: date->modified-julian-day date

Function: date->time-monotonic date

Function: date->time-tai date

Function: date->time-utc date

Function: julian-day->date jdn [tz-offset]

Function: julian-day->time-monotonic jdn

Function: julian-day->time-tai jdn

Function: julian-day->time-utc jdn

Function: modified-julian-day->date jdn [tz-offset]

Function: modified-julian-day->time-monotonic jdn

Function: modified-julian-day->time-tai jdn

Function: modified-julian-day->time-utc jdn

Function: time-monotonic->date time [tz-offset]

Function: time-monotonic->time-tai time

Function: time-monotonic->time-tai! time

Function: time-monotonic->time-utc time

Function: time-monotonic->time-utc! time

Function: time-tai->date time [tz-offset]

Function: time-tai->julian-day time

Function: time-tai->modified-julian-day time

Function: time-tai->time-monotonic time

Function: time-tai->time-monotonic! time

Function: time-tai->time-utc time

Function: time-tai->time-utc! time

Function: time-utc->date time [tz-offset]

Function: time-utc->julian-day time

Function: time-utc->modified-julian-day time

Function: time-utc->time-monotonic time

Function: time-utc->time-monotonic! time

Function: time-utc->time-tai time

Function: time-utc->time-tai! time

Convert between dates, times and days of the respective types. For instance time-tai->time-utc accepts a time object of type time-tai and returns an object of type time-utc.

The ! variants may modify their time argument to form their return. The plain functions create a new object.

For conversions to dates, tz-offset is seconds east of Greenwich. The default is the local timezone, at the given time, as provided by the system, using localtime (see Time).

On 32-bit systems, localtime is limited to a 32-bit time_t, so a default tz-offset is only available for times between Dec 1901 and Jan 2038. For prior dates an application might like to use the value in 1902, though some locations have zone changes prior to that. For future dates an application might like to assume today’s rules extend indefinitely. But for correct daylight savings transitions it will be necessary to take an offset for the same day and time but a year in range and which has the same starting weekday and same leap/non-leap (to support rules like last Sunday in October).