• d-bugmail puremagic.com (56/57) Dec 26 2020 https://issues.dlang.org/show_bug.cgi?id=21507

d-bugmail puremagic.com writes:

https://issues.dlang.org/show_bug.cgi?id=21507

          Issue ID: 21507
           Summary: SysTime.toISOExtString is unusable for logging or
                    consistent filename creation
           Product: D
           Version: D2
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P1
         Component: phobos
          Assignee: nobody puremagic.com
          Reporter: witold.baryluk+d gmail.com

If one wants to have sub-second resolution in logs, console or in filenames,
then SysTime toISOExtString (and toISOString too), are not usable:

Clock.currTime!(ClockType.coarse)(UTC()).toISOExtString()

2020-12-27T03:41:04.9671652Z
2020-12-27T03:41:05.067168Z
2020-12-27T03:41:05.1671Z
2020-12-27T03:41:06Z


Even worse, in some situations, it will align to the right, totally breaking a
lot of things.

toISOExtString (and toISOString) specification reads:

 Note that the number of digits in the fractional seconds varies with the
number of fractional seconds. It's a maximum of 7 (which would be hnsecs), but
only has as many as are necessary to hold the correct value (so no trailing
zeroes), and if there are no fractional seconds, then there is no decimal
point. 


This is the issue. While, it is possible to fix alignment to be consistent by
nulling the sub-seconds of the returned SysTime, it is not possible to
consistently format SysTime with sub-second resolution, without reimplementing
toISOExtString from scratch or parsing back (sic!) returned string and
reconstructing it again, which is madness. And reimplementing is non-trivial
and error-prone, due to leap seconds and negative hnsec.

I think toISOExtString should have a template parameter stating a desired
sub-second accuracy (-1, 0, 1, ..., 9). -1 being current variable / automatic
way. The other using fixed number of digits after decimal point. (Yes, 9 would
add always 00 at the end).

For example, above example could then look like this:


2020-12-27T03:41:04.967165200Z
2020-12-27T03:41:05.067168000Z
2020-12-27T03:41:05.167100000Z
2020-12-27T03:41:06.000000000Z


or like this

2020-12-27T03:41:04.967165Z
2020-12-27T03:41:05.067168Z
2020-12-27T03:41:05.167100Z
2020-12-27T03:41:06.000000Z


or like this:

2020-12-27T03:41:04.967Z
2020-12-27T03:41:05.067Z
2020-12-27T03:41:05.167Z
2020-12-27T03:41:06.000Z

depending on the template parameter (9, 6, 3 respectively).

The additional issue is the Z at the end. Which should be possible to remove
(this is permited by ISO 8601). The problem is if for logging one uses UTC
elusively, and even if local time zone is UTC, the Z is added, when it often
should be permited to be always dropped. This right now is not possible with
current toISOExtString interface.

--