Time library discussion (reprise)

[Juanma Barranquero]

On Tue, 11 Nov 2003 12:44:59 -0000
"Simon Marlow" <simonmar at microsoft.com> wrote:

> This has been demonstrated - recently by Juanma Barranquero's library
> posted to the Haskell list,

I think you're referring to Stefan Karrmann's library. I just did a
couple comments about it.

> Personally I think it's ok to have a library that "does its best" to
> give you the correct TAI time, with documented caveats.  IIRC, this is
> where we got stuck.

FWIW, after taking a look to Stefan's Tai.lhs, I think it is interesting
but way too complex. Many languages make do with things more or less
equivalent to the following (ripped from the Time::Piece Perl module,
which implements an interface outlined by Larry Wall time ago):

        $t->sec                 # also available as $t->second
        $t->min                 # also available as $t->minute
        $t->hour                # 24 hour
        $t->mday                # also available as $t->day_of_month
        $t->mon                 # 1 = January
        $t->_mon                # 0 = January
        $t->monname             # Feb
        $t->month               # same as $t->monname
        $t->fullmonth           # February
        $t->year                # based at 0 (year 0 AD is, of course 1 BC)
        $t->_year               # year minus 1900
        $t->yy                  # 2 digit year
        $t->wday                # 1 = Sunday
        $t->_wday               # 0 = Sunday
        $t->day_of_week         # 0 = Sunday
        $t->wdayname            # Tue
        $t->day                 # same as wdayname
        $t->fullday             # Tuesday
        $t->yday                # also available as $t->day_of_year, 0 = Jan 01
        $t->isdst               # also available as $t->daylight_savings

        $t->hms                 # 12:34:56
        $t->hms(".")            # 12.34.56
        $t->time                # same as $t->hms

        $t->ymd                 # 2000-02-29
        $t->date                # same as $t->ymd
        $t->mdy                 # 02-29-2000
        $t->mdy("/")            # 02/29/2000
        $t->dmy                 # 29-02-2000
        $t->dmy(".")            # 29.02.2000
        $t->datetime            # 2000-02-29T12:34:56 (ISO 8601)
        $t->cdate               # Tue Feb 29 12:34:56 2000
        "$t"                    # same as $t->cdate

        $t->epoch               # seconds since the epoch
        $t->tzoffset            # timezone offset in a Time::Seconds object

        $t->julian_day          # number of days since Julian period began
        $t->mjd                 # modified Julian date (JD-2400000.5 days)

        $t->week                # week number (ISO 8601)

        $t->is_leap_year        # true if it its
        $t->month_last_day      # 28-31

        $t->time_separator($s)  # set the default separator (default ":")
        $t->date_separator($s)  # set the default separator (default "-")
        $t->day_list(@days)     # set the default weekdays
        $t->mon_list(@days)     # set the default months

        $t->strftime(FORMAT)    # same as POSIX::strftime (without the overhead
                                # of the full POSIX extension)
        $t->strftime()          # "Tue, 29 Feb 2000 12:34:56 GMT"

        Time::Piece->strptime(STRING, FORMAT)
                                # see strptime man page. Creates a new
                                # Time::Piece object

and even that could be reduced considerably.

IMHO, Haskell should have a simple module which allowed to manipulate
dates and times in UTC (and convert to/from localtimes, and perhaps
MJD/JD), and, as an extension, a TAI module for the (probably very few)
people who needs that kind of precision.

I know that I've been programming quite a few years and I've never
needed to know TAI times, nor ignoring the leap seconds have been a
problem. And, till very recently, I was working for a VoIP carrier, so
you can bet we manipulated dates, times and durations *constantly*. I'm
not saying there aren't problem domains where that level of precision is
required. Just they're not that common, I think.

                                                                Juanma