Re: [Help-glpk] Time conversion functions

[Andrew Makhorin]

Hi Xypron,

> The offset between UTC and local time is not a constant due to day light
> saving time.

> In German local time there are only 11 hours from 00:00 on the last
> sunday in march to 12:00 on the same day. There are 13 hours from 00:00
> to 12:00 on the last sunday in october. In UTC time from 00:00 to 12:00
> there are always 12 hours.

> How would you express
> Oct 26, 2008 02:30a (summer time) and
> Oct 26, 2008 02:30b (winter time)
> which are 60 minutes apart in GLPK if we used local time?

> When dealing with models that span different time zones - as is often
> the case in scheduling - working in UTC is the only way to write
> consistent models.

> I have colleagues in India and the US. How could we ever use the same
> model if it was in local time?

> Hence I want to have my models in UTC.

> We should keep local time out of GLPK models. All numerics representing
> time should be in UTC. This will guarantee that all users will get the
> same result for a model file at the same time.

> Hence time() should return the current UTC time. Please, replace
> localtime by gmtime in function time().

Okay. I will either change time() to return UTC rather than the local
time, or add another function, for example, gmtime().

> If a user has data in a local time this should be handled in the
> str2time() (and possibly in time2str). This is why I ask for code '%z'
> being added to str2time.

The concept of the local time assumes using the timezone and daylight
save info on converting UTC to the local time and vice versa. This is
normal, for example, in e-mail messages, but, in my opinion, using the
daylight save time in modeling is an extremely bad idea for the following
reasons. (1), there may be invalid time points, namely, which belongs to
a non-existing hour on swithcing from the winter time to summer one and
which therefore cannot be mapped to any UTC. (2), there may be
undistinguishable time points which belongs to a "double" hour appearing
on switching from the summer time to winter one. And (3), the rules that
regulates the daylight save info for different countries are completely
unpredictable and cannot be formalized. Thus, converting UTC to the local
time in time2str and the local time to UTC in str2time make things
extremely difficult, unclear, and unreliable.

To avoid such artificial problems I propose that I did--to implement
time2str and str2time simply as formatting functions, which do not take
into account the timezone and daylight save info, and where the calendar
time, t, passed to time2str and reported by str2time is just a "plain"
time which is the number of seconds elapsed since 1970-01-01 00:00:00.
It is *not* defined whether t is UTC, local time, or somewhat else.
If you deal with UTC, you may think t as UTC. If you deal with a local
time, you may think t as the local time. If in your model t is UTC, and
you need to convert it to a local time, you should add the time offset
which takes into account the timezone and daylight saving info and is
defined in your model. If you need to deal with local times around the
globe, you may use a database to determine the time offset for each
particular location.


Andrew Makhorin