Re: [Help-glpk] Time conversion functions

[xypron]

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.