Re: [Help-glpk] Time conversion functions

[Andrew Makhorin]

[This is a copy of the message.]

Hi Xypron,

Please see the distribution tarball attached.

Based on your code you posted to me I implemented the following two
functions (see src/glpmpl05.c and also examples/cal.mod):

str2time(s, fmt)
   Converts the specified character string s to the calendar time using
   the format control string fmt, where the calendar time is the number
   of seconds elapsed since 1970-01-01 00:00:00 for the same timezone.
   The range allowed is [0001-01-01 00:00:00..4000-12-31 23:59:59].

   Currently the following specifiers are implemented:
   %b, %d, %h, %H, %m, %M, %S, %Y.

   Missing date/time components not specified in the input string are
   set to default values which are 1970-01-01 00:00:00. Thus, for
   example, str2time("Nov;53", "%b;%M") returns the calendar time
   corresponding to 1970-11-01 00:53:00. Sometimes this convention may
   be useful.

time2str(t, fmt)
   Converts the specified calendar time to a character string using the
   format control string fmt.

   Currently the following specifiers are implemented:
   %a, %A, %b, %B, %C, %d, %D, %e, %F, %h, %H, %I, %j, %k, %l, %m, %M,
   %p, %P, %r, %R, %S, %T, %u, %w, %y, %Y.

Also I changed the code to allow conversion from symbolic value, which
is a character string, to numeric one. Thus, for example, the day of the
month can be computed as follows:

   param day := time2str(t, "%d");

though time2str returns a character string, not a number.

The function now(), which returns the local calendar time, is not
implemeted yet. However, it can be easily simulated with str2time.

As to timezone info, I propose not to implement it at all for the
following reason. If we deal only with local times for a particular
timezone, we always can define, if necessary, the time offset, say, as
a model parameter to convert the local times to UTC and vice versa. On
the other hand, if we model something around the globe (for example,
flights between airports), the timezone information provided by
standard C functions does not help, because then we need to know the
time offsets for *all* locations, not only for one location, where we
sit. And again, we can use a database (CSV file, for example) to define
the time offsets for all locations used in the model.


Best regards,

Andrew Makhorin