Thread: [Sccs-devel] Bugs handling UTC in 5.08
The UNIX Source Code Control System activelty maintained/enhanced
Brought to you by:
schily
Menu
▾
▴
sccs-devel
|
From: Bruce L. <bru...@gm...> - 2015-10-13 00:57:31
Attachments:
patch.utc
|
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.
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).
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:
1. CCSDS 301.0-B-4 section 3.5 type A and B formats
* http://public.ccsds.org/publications/archive/301x0b4e1.pdf
2. EDSC EX000013.1
* Http://www.exchangenetwork.net/standards/
Rep_Date_Time_01_06_2006_Final.pdf
3. RFC 3339
* https://www.ietf.org/rfc/rfc3339.txt
Note: all of the above are freely available at the URIs provided. They
are all based on ISO 8601 (which is not freely available and is
expensive).
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.
Incidentally, "GMT" is ambiguous and is considered archaic; better to use
"UTC". Refer to:
* http://www.ucolick.org/~sla/leapsecs/timescales.html
and the references therein, especially:
* http://articles.adsabs.harvard.edu/full/1978QJRAS..19..290S
Patch attached.
|
|
From: Joerg S. <Joe...@fo...> - 2015-10-13 12:44:46
|
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/'
|
|
From: Bruce L. <bru...@gm...> - 2015-10-13 16:07:07
|
Partial response: On Tue, Oct 13, 2015 at 8:44 AM, Joerg Schilling <Joe...@fo...> wrote: > 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? With prs.c patched but w/o the patch to dodelt.c: Script started on Tue Oct 13 11:48:58 2015 # date -u +%%Z%%%Y-%m-%dT%H:%M:%SZ > test.txt # /opt/schily/ccs/bin/admin -itest.txt s.test.txt # rm test.txt # /opt/schily/ccs/bin/get s.test.txt Time stamp later than current clock time (co10) 1.1 1 lines # head -99 test.txt s.test.txt ==> test.txt <== @(#)2015-10-13T15:49:03Z ==> s.test.txt <== h09367 s 00001/00000/00000 d D 1.1 15/10/13 15:49:09 root 1 0 c date and time created 15/10/13 15:49:09 by root e u U f e 0 G r t T I 1 %Z%2015-10-13T15:49:03Z E 1 # Script done on Tue Oct 13 11:49:55 2015 Note the erroneous co10 error message. >> 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? The purpose is to provide expansion of date-time in standard format. > 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. But the p-file isn't, and the existing format suffer from all of the problems that you noted (and more): [...] > 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. |
|
From: Joerg S. <Joe...@fo...> - 2015-10-13 16:23:12
|
Bruce Lilly <bru...@gm...> wrote:
> > Could you please give a test case for the problem you have in mind?
>
> With prs.c patched but w/o the patch to dodelt.c:
>
> Script started on Tue Oct 13 11:48:58 2015
> # date -u +%%Z%%%Y-%m-%dT%H:%M:%SZ > test.txt
> # /opt/schily/ccs/bin/admin -itest.txt s.test.txt
> # rm test.txt
> # /opt/schily/ccs/bin/get s.test.txt
> Time stamp later than current clock time (co10)
> 1.1
> 1 lines
> # head -99 test.txt s.test.txt
> ==> test.txt <==
> @(#)2015-10-13T15:49:03Z
>
> ==> s.test.txt <==
> h09367
> s 00001/00000/00000
> d D 1.1 15/10/13 15:49:09 root 1 0
> c date and time created 15/10/13 15:49:09 by root
> e
> u
> U
> f e 0
> G r
> t
> T
> I 1
> %Z%2015-10-13T15:49:03Z
> E 1
> #
>
> Script done on Tue Oct 13 11:49:55 2015
>
> Note the erroneous co10 error message.
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.
> >> 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?
>
> The purpose is to provide expansion of date-time in standard format.
There are so many standards for time stamps, why do you believe that the ony
you selected is superior to others?
> > The format of the s.files is bejond POSIX.
>
> 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.
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/'
|
|
From: Bruce L. <bru...@gm...> - 2015-10-13 19:26:04
|
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). [...] >> The purpose is to provide expansion of date-time in standard format. > > 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). In addition the format is used nearly ubiquitously in computing: https://technet.microsoft.com/en-us/library/ms190977%28v=sql.90%29.aspx http://www.w3.org/QA/Tips/iso-date http://www.w3.org/TR/NOTE-datetime http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#isoformats http://microformats.org/wiki/iso-8601 http://www.uic.edu/depts/accc/software/isodates/index.html http://support.sas.com/documentation/cdl/en/leforinforref/64790/HTML/default/viewer.htm#p1a0qt18rxydrkn1b0rtdfh2t8zs.htm http://php.net/manual/en/function.date.php https://www.gnu.org/software/emacs/manual/html_node/calc/ISO-8601.html http://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-DATETIME-DATE-TABLE http://filmstandards.org/fiaf/wiki/doku.php?do=export_raw&id=date_types http://code.logos.com/blog/2009/04/datetime_and_iso8601.html Need more examples?: https://duckduckgo.com/?q=ISO+8601&ia=about As far as I know, none of the ones presently used in SCCS are compliant with any de jure 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! ISO 8601 and its derivatives always present components from most to least significant: years, months, days, hours, minutes, seconds; the text version can therefore be easily sorted chronologically. See http://www.iso.org/iso/home/standards/iso8601.htm and https://en.wikipedia.org/wiki/ISO_8601 The major disadvantage of ISO 8601 per se (aside from the price) is the many cases of exceptions allowed "by mutual agreement" which isn't possible for published documents. The three freely available standards which I mentioned do not suffer from that defect. >> > The format of the s.files is bejond POSIX. >> >> 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). |
|
From: Joerg S. <Joe...@fo...> - 2015-10-14 12:56:09
|
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/' |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X