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

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

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

> This started as a bug-fix for prs.c, which wouldn't compile with
> -DGMT_TIME.  During testing, I found several related bugs, and added some
> related features which I've been using locally for some time.  These may
> help with v6.

No, SCCSv6 does not need the workaround introduced by Sun between 1990 and 2006.
This is because SCCS now supports much better and unique time stamp handling 
that includes GMT-offset.

> Related bugs fixed:
>
>  * Incorrect time (not corrected for zone offset) resulting in warnings
>    about retrieval time being older than delta time (noticeable West of the
>    Prime Meridian).

Could you please give a test case for the problem you have in mind?


> Related features added:
>
>  * %N% and %O% keywords added and documented.
>
>    These are for current date-time and last applied delta date-time,
>    respectively.  Format is standard date-time format as documented in:

What is the main purpose for this modification?
Note that upper case keywords as extensions are not a good idea as they are
always enabled by default and thus cause compatibility problems with older SCCS 
versions.

...
>    Examples:
>        %N% 2015-10-11T17:55:49.104271752Z
>        %O% 2015-10-11T11:45:16Z
>
>  * Improved parsing of date and time.
>
>    In case XPG decides to allow or require standard format date-time in the
>    s-file.

The format of the s.files is bejond POSIX.

This is why SCCSv6 will still be POSIX compliant as the s-file format changes 
are outside of the specification. 

The goal for the SCCSv4 vs. SCCSv6 format change was to chnage as few things as 
possible but still make the known problems disappear. The problems have been:

-	2-digit years is a real problem, fixed by using 4+ digits in V6

-	local time without GMT-offset causes undeterminable time stamps.
	The problem is even present when always operating in the same timezone
	as there are DST switches that may the time to appear going backwards.
	Fixed by always adding a GMT offset.

-	coarse time resolution, fixed by optional second fraction up to 
	nanosecond resolution.


> Incidentally, "GMT" is ambiguous and is considered archaic; better to use
> "UTC".  Refer to:

As UNIX does not use leap seconds, I believe there is no difference on UNIX.

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/'