www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 21507] New: SysTime.toISOExtString is unusable for logging or


          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:



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
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. --
Dec 26 2020