RE: Time library discussion (reprise)
I noted this in the draft communities report:
[[ Currently, the discussion has stalled again. The leap seconds issue is something of a sticking point, and there are some implementability question marks over other parts of the API. Contribution to (any aspect of) the discussion is welcomed. ]]
As a process meta-issue, I would ask: is there an approach we can adopt that allows the concerns about implementability of leap-seconds to be deferred to a later stage, to the maximum extent possible.
My simple-minded view is that an approach based on an underlying value a pair of values (e.g. days,picoseconds) would allow systems implemented without concern for leap seconds to be adequate for a good number of practical applications. And systems that do know about leap seconds can do a better job.
I don't think this solves the problem (but I might be wrong). We have no problem with doing calculations on TAI time, and doing conversions between TAI and UTC. This has been demonstrated - recently by Juanma Barranquero's library posted to the Haskell list, and I also hacked up a simple TAI library a while ago (though not nearly as complete as Juanma's). The problem is how to get access to TAI time on Unix systems (and indeed other OSs, probably). Unix systems provide something called time_t, which is a timescale that doesn't include leap seconds. Strange things happen on a Unix system when a leap second occurs: the proper way (it seems) to deal with leap seconds is to slow down the system clock a bit until the actual time catches up with time_t again. The point is that if you only have access to time_t, and you don't know what the system is doing with leap seconds, you can't tell what the time is. I'm sure that most people don't care about this (I certainly don't :-). 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. Also, I believe the proposed System.Time library had some functionality which is difficult to implement on Unix systems (eg. a function to convert a timezone name to a GMT offset isn't available AFAIK). Cheers, Simon
On Tue, 11 Nov 2003 12:44:59 -0000
"Simon Marlow"
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
participants (2)
-
Juanma Barranquero -
Simon Marlow