> What is missing in your > proposal is the handling of durations. I think such function is not needed, since conversion of the time interval from days/hours/minutes to seconds is quite easy and does not cause any troubles.
>>>localtime() >>> Returns the current local calendar time (volatile). > This function I called now(). > It should return seconds since 1970-01-01T00:00:00Z as numeric. > Time zone dependencies should only exist in the external representation. > This is why I created two functions to convert time in seconds since 1970 to > a string representation which i called: > localtime( t, fmt) > gmtime( t, fmt) Timezone info is badly specified and may cause annoying portability problems. It is needed in the internet applications while on modeling it is not needed as my practice shows. Besides, as I already noticed, it is always possible to define the timezone offset directly in the model. Besides, now we have data tables, don't we? So we could prepare a table (say, in csv format) containing timezone info, if necessary. _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
