[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] Time conversion functions
From: |
Andrew Makhorin |
Subject: |
Re: [Help-glpk] Time conversion functions |
Date: |
Sun, 23 Nov 2008 07:01:05 +0300 |
[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
- Re: [Help-glpk] Time conversion functions, (continued)
- Re: [Help-glpk] Time conversion functions, Xypron, 2008/11/22
- Re: [Help-glpk] Time conversion functions, Andrew Makhorin, 2008/11/22
- Re: [Help-glpk] Time conversion functions, Xypron, 2008/11/22
- Re: [Help-glpk] Time conversion functions, Andrew Makhorin, 2008/11/23
- Message not available
- Message not available
- Message not available
- Message not available
- Re: [Help-glpk] Time conversion functions, Xypron, 2008/11/24
- Re: [Help-glpk] Time conversion functions, Andrew Makhorin, 2008/11/25
- Re: [Help-glpk] Time conversion functions, glpk xypron, 2008/11/25
- Re: [Help-glpk] Time conversion functions, Andrew Makhorin, 2008/11/18
- Re: [Help-glpk] Time conversion functions, Harley Mackenzie, 2008/11/18
- Re: [Help-glpk] Time conversion functions, Nigel Galloway, 2008/11/19
- Re: [Help-glpk] Time conversion functions,
Andrew Makhorin <=