From: Nicolas C. <war...@fr...> - 2004-08-11 11:59:52
|
Here's a datetime module interface proposal open to comments. I agree to implement it if we reach an agreeement. --------------------- type day = Mon | Tue | Wed | Thu | Fri | Sat | Sun type month = Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec type date_time val now : unit -> date_time val date : day:int -> month:int-> year:int -> date_time val time : sec:int -> min:int -> hour:int -> date_time val add : date_time -> date_time -> date_time val sub : date_time -> date_time -> date_time val day : date_time -> int (* 1-31 *) val week_day : date_time -> day val year_day : date_time -> int (* 1-366 *) val month : date_time -> month val month_number : date_time -> int (* 1-12 *) val year : date_time -> int (* 4 digits *) val hour : date_time -> int (* 0-23 *) val min : date_time -> int (* 0-59 *) val sec : date_time -> int (* 0-59 *) type locale = US | UK | FR | DE | JP val format : string -> ?locale:locale -> date_time -> string (* format rules : %m : month , 2 digits %M : month name (depends of the locale) %y : year, 2 digits %Y : year, 4 digits %d : day of month %D : day name (depends of the local) %s : seconds (2 digits) %S : seconds (1 - 2 digits) %i : minutes (2 digits) %I : minutes %h : hours (2 digits) %H : hours other caracters are not translated , just outputed to the buffer so one can write Date.format "%d-%m-%Y" or Date.format "%y/%m/%d" for selecting separators. *) ------------- other primitives that could be added : val utc : date_time -> float (* identity *) val ymd : date_time -> int * int * int val hms : date_time -> int * int * int and all support for business weeks, leap years, and anything you might need.... Regards, Nicolas Cannasse |
From: Richard J. <ri...@an...> - 2004-08-11 12:14:54
|
On Wed, Aug 11, 2004 at 01:58:52PM +0200, Nicolas Cannasse wrote: > Here's a datetime module interface proposal open to comments. > I agree to implement it if we reach an agreeement. Have to say it: disagree strongly. Dates are one thing. Times (date-time) quite another issue. A very complex issue which I don't think anyone on this list is clued in enough to code. See Bardur's message (Message-ID: <200...@sc...>) for issues with representation as float. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment Perl4Caml lets you use any Perl library in your type-safe Objective CAML programs. http://www.merjis.com/developers/perl4caml/ |
From: Bardur A. <oca...@sc...> - 2004-08-11 12:38:49
|
On Wed, Aug 11, 2004 at 01:14:43PM +0100, Richard Jones wrote: > On Wed, Aug 11, 2004 at 01:58:52PM +0200, Nicolas Cannasse wrote: > > Here's a datetime module interface proposal open to comments. > > I agree to implement it if we reach an agreeement. > > Have to say it: disagree strongly. Me too. The first thing that caught my eye was the lack of higher-than-1-second precision. > > Dates are one thing. > You know, the more I think about it... You're absolutely right! :) The dates you're talking about (I'll call them "logical dates") are actually quite orthogonal to any "real world" dates/times and so should be actually be kept completely separate from any module which deals with the "real" time. If you think about it, deltas between dates can mean two very different things depending on whether we're talking about "real" dates or merely logical dates. Example: Real dates aren't always "1 day" apart in as much as 1 day is not actually always 86400 seconds, whereas logical dates *are* always precisely 1 day apart. > Times (date-time) quite another issue. A very complex > issue which I don't think anyone on this list is clued in > enough to code. See Bardur's message (Message-ID: > <200...@sc...>) for issues with > representation as float. > Agreed, my vote goes to including GregorianDate and to *NOT* trying to implement any DateTime. Maybe if someone who happens to be an expert on such matters decides to donate a module, then great, but I think it is foolish to think that it's just a matter of writing some code. There are lots and lots (and lots and lots...) of things that can go wrong. -- Bardur Arantsson <ba...@im...> <ba...@sc...> Not all pain is gain. http://www.demotivators.com |
From: Achim B. <bl...@la...> - 2004-08-11 12:25:42
|
Nicolas Cannasse wrote: > > type locale = US | UK | FR | DE | JP Why hardcode a small set of locales? Wouldn't it be better to define something like type locale = (day -> string) * (month -> string); Achim -- ________________________________________________________________________ | \_____/ | Achim Blumensath \O/ \___/\ | LaBRI / Bordeaux =o= \ /\ \| www-mgi.informatik.rwth-aachen.de/~blume /"\ o----| ____________________________________________________________________\___| |
From: Jesse G. <je...@wi...> - 2004-08-11 14:31:55
|
Nicolas Cannasse wrote: > Here's a datetime module interface proposal open to comments. > I agree to implement it if we reach an agreeement. I like it. It isn't anywhere near perfect, but most of the time you don't need perfect, just Good Enough. You people that need sub-second precision should write your own module, otherwise we will continue to have nothing, and this module is a lot better than nothing. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net |
From: Nicolas C. <war...@fr...> - 2004-08-11 15:31:18
|
> Nicolas Cannasse wrote: > > > Here's a datetime module interface proposal open to comments. > > I agree to implement it if we reach an agreeement. > > I like it. It isn't anywhere near perfect, but most of the time > you don't need perfect, just Good Enough. You people that need > sub-second precision should write your own module, otherwise > we will continue to have nothing, and this module is a lot better > than nothing. That's also my point. If some people think that having below day date precision is a bad thing, then they can simply ignore that precision by manipulating only days-rounded datetimes. I understand correctly the problems with UTC and leap seconds, but I think that having a 22seconds difference over a 30 years time period is not a big problem unless you're doing very precise calculations, and then we can eventualy put a warning in the library docs for such users, while still helping a lot of people with date/time manipulation. Concerning the precision of floats, using an Int64 is sure a better thing as Brian showed it. I also agree with : type locale = (day -> string) * (month -> string) from Achim . This way the library can be more easily extended with specific or exotic printers ( a startrek time pp anyone ? ) Nicolas Cannasse |
From: Francisco V. <fv...@ts...> - 2004-08-12 17:59:49
|
Hi, Jesse Guardiani wrote: >Nicolas Cannasse wrote: > > > >>Here's a datetime module interface proposal open to comments. >>I agree to implement it if we reach an agreeement. >> >> > >I like it. It isn't anywhere near perfect, but most of the time >you don't need perfect, just Good Enough. You people that need >sub-second precision should write your own module, otherwise >we will continue to have nothing, and this module is a lot better >than nothing. > > I think the "better than nothing" approach here is sensible if the CAVEATs about the use of the module for purposes other than those it was made for are stated in the doc. On the coding style, though (and this is just a style question, mind you, so its completely conventional), why won't you make use of module nesting & such to collect all information like (* in file date.ml so that everything becomes Date.<whatever> *) type month = type weekday = module Time = sig type t val now : unit -> t val date : day:int -> month:int-> year:int -> t val time : sec:int -> min:int -> hour:int -> t val add :t -> t -> t val sub :t -> t -> t (* ... *) end I think this helps organise the module, the doc and the mental image of it in your mind... (Or maybe I am becoming too "module oriented"...) Anyway, it's only a suggestion for improvement, please go on with your proposed approach if you don't find here anything interesting... I'd rather see your proposal *coded* than mine *discussed*... ;) Regards and keep on with the good job, Francisco Valverde Univ. Carlos III de Madrid (visiting at ICSI, Berkeley) > > |