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

[Bruce L. <bru...@gm...>]

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).