[m-rev.] for review: smart recompilation

[Fergus Henderson]

On 30-May-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> On 29-May-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 28-May-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > library/time.m:
> > > 	Add undocumented predicates to convert time_t to and from int.
> > > 	They are undocumented because they rely on the assumption that
> > > 	`time_t' fits in a Mercury `int'.
> > 
> > I don't think this is a good idea, if it can be avoided.
> > It would be better to write the code in a way which doesn't
> > rely on that assumption.
> > 
> > Also it would not be a great idea to write out time_t values as ints
> > into files, since that would cause problems if the time_t representation
> > is not the same on all platforms that access those files.
> > 
> > Instead, how about writing out the time_t values as strings,
> > e.g. in yyyy-mm-dd hh:mm:ss format, and then parsing them back in again?
> > 
> > The output can be done by
> > 
> > 	char buf[sizeof "yyyy-mm-dd hh:mm:ss"];
> > 	strftime(buf, sizeof buf, "%Y-%m-%d %H:%M:%S", tm_ptr);
> > 
> > If we could rely on X/Open, we could also use strptime() to parse it,
> > but it would probably be best to roll our own.
> 
> That sounds like a good idea, but in practice it's a bit painful.
> 
> We need to write time values in UTC (otherwise known as Greenwich
> Mean Time) to avoid problems with daylight saving time or users
> changing timezones. The problem with that is that POSIX does not
> provide a portable way to convert a broken down time (struct tm)
> containing a UTC time into a time_t. (mktime() converts a `struct tm'
> containing a local time into a time_t).

I think that may not be the only problem.
Why do you want to convert it back to time_t?
If you want to do it to compare dates to see which is earlier,
then beware that even if there was a portable way to convert a struct tm
containing a UTC time into a time_t, the results of comparing time_t
values is not guaranteed by the C or Posix standards.
time_t is guaranteed to be an arithmetic type, but nothing is guaranteed about
the representation within that type; tecnically you can't safely compare
two time_t using `<' and rely on the ordering matching the time ordering.
(That's according to the standard.  There's probably a fairly good
chance that it will work OK in practice, though.)

> As far as I can tell, the only other alternative is to pass timestamps
> around as type `tm', or as strings formatted as above, rather than
> `time_t'. Given that we don't actually care about contents of the time
> values, just comparison between time values, I prefer the formatted
> strings option.  The `tm' values contain fields for day of week,
> day of year and daylight saving time, which aren't used, and which
> cause similar problems with comparisons as the `term__context' fields
> in `prog_data__type's.
> 
> Comments?

Passing around strings formatted in ISO date format sounds good to me.
Just make sure you use an ADT to isolate the code which depends on the
representation.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------