Hello Andrew, ISO 3601 both defines formats for local time and for time with a reference to a time zone given as offset to UTC.
Handing time zone information with an offset given in hours and minutes is straightforward (e.g. 1970-01-01T12:00:00+0800 = 1970-01-01T20:00:00Z = 72000 s [after 1970-01-01T00:00:00Z]). I would not like to support named timezones due to the reason given in RFC3339: "Because the daylight saving rules for local time zones are so convoluted and can change based on local law at unpredictable times, true interoperability is best achieved by using Coordinated Universal Time (UTC)." As C99 does define a conversion function from a structure tm in UTC to time_t as last resort GLPK should be able to handle local timestamps. For systems using GLIBC or VisualC a conversion from UTC is possible. Marc pointed out that my first proposal missed durations. I have added to my implementation function dur2str( num, fmt) which allows output of durations in conformance with ISO 8601. The model ( http://glpk.dyndns.org/viewvc/svn/glpk/glpk/branches/glpk-4.33-strdate/examples/date.mod?view=markup example/date.mod ) below shows how the time conversion functions I implemented could be used. The files of my implementation can be download with subversion as svn co http://glpk.dyndns.org/svn/glpk/glpk/branches/glpk-4.33-strdate http://glpk.dyndns.org/svn/glpk/glpk/branches/glpk-4.33-strdate or viewed (including diffs) on http://glpk.dyndns.org/viewvc/svn/glpk/glpk/branches/glpk-4.33-strdate http://glpk.dyndns.org/viewvc/svn/glpk/glpk/branches/glpk-4.33-strdate Adding the capability to access the month or the week of a timestamp makes sense because a lot of supply chain optimization models are based on periodic planning. Determining the month with the proposed functions is straightforward: param current_month symbolic := localtime(now(), '%Y-%m'); # e.g. '2008-11' The week can be determined with: param current_week symbolic := localtime(now(), '%Y-%WW'); # e.g. '2008-48W' Best regards Xypron /* Date Conversion */ param tims symbolic; param timd := str2time( tims, "%Y-%m-%dT%H:%M:%S%z"); param timl symbolic := localtime(timd, "%Y-%m-%dT%H:%M:%S"); param timg symbolic := gmtime(timd, "%Y-%m-%dT%H:%M:%SZ"); param nowd := now(); param nowl symbolic := localtime( nowd, "%Y-%m-%dT%H:%M:%S"); param nowg symbolic := gmtime( nowd, "%Y-%m-%dT%H:%M:%SZ"); param dur; param durs symbolic := dur2str(dur, "P%dDT%HH%MM%S.S"); solve; printf "Timestamp = %s\n",tims; printf "Local time = %s\n",timl; printf "Global time = %s\n",timg; printf "\n"; printf "Current local time = %s\n",nowl; printf "Current global time = %s\n",nowg; printf "\n"; printf "Duration = %d\n",dur; printf "Duration = %s\n",durs; /* Expected output Timestamp = 2008-11-15T13:22:10+0300 Local time = 2008-11-15T17:22:10 (for timezone +0100) Global time = 2008-11-15T16:22:10Z Duration = P271DT11H09M49.33S */ data; param tims := "2008-11-15T13:22:10+0300"; param dur := -23454589.34; end; Andrew Makhorin wrote: > > > Thank you for your proposal. > > In fact, inclusion of date/time functions in mathprog would be very > useful. However, it seems to me that using timezone info is an > unnecessary feature. > > I suggest to implement two date/time formats. One is the number > of seconds since 1970-01-01 00:00:00 represented as a floating-point > number suitable for arithmetic calculations, and another is a > character string suitable for external representation. Then there > should be two functions to convert between these two formats, and > probably some functions to access components of the timestamp like > year, month, etc. > > > -- View this message in context: http://www.nabble.com/Time-conversion-functions-tp20549985p20569127.html Sent from the Gnu - GLPK - Help mailing list archive at Nabble.com. _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
