Re: [Sccs-devel] Bugs handling UTC in 5.08

[Joerg S. <Joe...@fo...>]

Bruce Lilly <bru...@gm...> wrote:

> On Tue, Oct 13, 2015 at 12:23 PM, Joerg Schilling
> <Joe...@fo...> wrote:
> > Bruce Lilly <bru...@gm...> wrote:
> [...]
> > OK, I'll have to look at this....
> >
> > The fact that you do just the opposite of what is already on the sources makes
> > me suspect a problem in your solution.
>
> By all means check it; at the moment, the zone offset here is -14400 seconds,
> so to get UTC from local time, the zone offset must be subtracted (note the
> local times from script vs. the UTC time from date and in the files from my test
> case report).

Avoiding a warning is not a proof for correct implementation.

Last evening, I verified that your solution for dodelt.c is indeed incorrect.
I still need to find a solution that is not in conflict with the GMT hack in 
get(1) and delta(1) that was introduce for performance reasons on SunOS-4.x and 
Linux as these systems do not have a timezone offset cache like Solaris.

> > There are so many standards for time stamps, why do you believe that the ony
> > you selected is superior to others?
>
> It is compliant with a published de jure international standard (ISO 8601) and
> with standards derived from that, including the three freely available ones
> mentioned in my initial bug report message, and with those based on it
> and/or the latter three (e.g. W3C, XML, and RFC 5424).  ISO 8601 is also
> the basis for many national standards, such as DIN ISO 8601, BS EN 28601,
> and ANSI INCITS 30-1997 (R2008). Others referencing ISO 8601 include
> DoD 5015.2 STD (http://www.dtic.mil/whs/directives/corres/pdf/501502std.pdf).

OK, I checked that DIN ISO 8601 was marked to replace DIN 1355, so it seems to 
be the major time format standard nowerdays.

> As far as I know, none of the ones presently used in SCCS are compliant with
> any de jure international standard.

Well, SCCS started in 1972 in the USA and it seems that it initially used the 
strange US date conventions.

All time stamp notations used by SCCS except for those in the s-files are part 
of the POSIX standard and as a result part of an international standard.


> The ones in SCCS are particularly bad: if a gotten file says 10/11/12
> for the date, the meaning depends on whether it came from %E% or %G%,
> and there's no clue in the file itself!

This is a result of the fact that US people introduced a date notation that is 
in conflict with any notation in the rest of the world. It seems that the UNIX 
people have been aware about this problem early and introduced alternate date 
formats.

It may be a useful enhancement to let SCCS optionally create DIN ISO 8601 time 
stamps at places that are not important for internal file formats. This seems 
to be expanded get(1) keywords for now. Do you know about other places that may 
be of interest?

It may also be useful to permit SCCS to be able to read cutoff time stamps in 
that format.

Given that I already mentioned that extended (what was not present in February 
1977 with SCCSv4) keyword definitions should be disabled by default to avoid 
unpredictable problems, I recommend the following new keyletters:

	%t%	Current time in RFC 3339 format: yyy-mm-ddThh:mm:ss[.frac][+|-}hh:mm]
	%u%	Newest applied delta time in RFC 3339 format: yyy-mm-ddThh:mm:ss[.frac][+|-}hh:mm]

Lower case keywords are disabled by default and need to be swiched on via 
admin(1) to be usable.


> >> But the p-file isn't, and the existing format suffer from all of the
> >> problems that you noted (and more):
> >
> > This is not a problem, as p-files are temporary files and as the timestamps in
> > these files are not used for storing anything in the history file.
>
> If a goal is for a distributed version control system, the p-files may
> be visible
> and the ambiguities (timestamp issues being only part of the problem) are
> relevant.  This is even the case for a single multiuser system (note that
> different users, possibly connecting remotely via ssh or similar, might
> have different environment TZ settings).

It is a pity that POSIX did not think about this possibility but we have to 
live with it. Because these time stamps are only used for informational 
purposes: "user xxx did edit this file at yyy", I do not see a real problem 
resulting from this local time format.

It may be that the reason why POSIX did define any semi permanent and permanent
file content but the s-file format is a result of the fact that AT&T offers 
"sablime" which is a hacked SCCS with binary history files.

In case of a SCCS configuration that disables concurrent edits, you may use 
filesystem timestamps from p-files.

In the other case, you will still know which edit started earlier, as the new 
content is appended to the existing p-file. I see no reason, why this 
informational time stamp needs to be more accurate than a day.

Jörg

-- 
 EMail:jo...@sc...                    (home) Jörg Schilling D-13353 Berlin
       joe...@fo... (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'