Bug 21507 – SysTime.toISOExtString is unusable for logging or consistent filename creation

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.

@lucica28 updated dlang/phobos pull request #8255 "Fix issue 21507 - added precision for function SysTime.toIsoExtString" fixing this issue: - Fix issue 21507 - added precision for function SysTime.toIsoExtString - Fix Issue 21507 - added precision for function SysTime.toIsoExtString https://github.com/dlang/phobos/pull/8255

You don't need to parse it, you can just append zeros: --- string want(string time, int num) { string tail=".000000000"; time=time[0..$-1]; if(num==0)return time[0..19]; if(time.length>=20+num)return time[0..20+num]; if(time.length>20) //1001-01-01T01:01:01Z return time~tail[$-(20+num-time.length)..$]; return time~tail[0..num+1]; } ---

dlang/phobos pull request #8255 "Fix issue 21507 - added precision for function SysTime.toIsoExtString" was merged into master: - e4bb5fcd9a70be456a2ef38190fedace10a0bafe by Lucian Danescu: Fix issue 21507 - added precision for function SysTime.toIsoExtString - 3700100f918aaca20219420e0136c5fdbed693a9 by Lucian Danescu: Fix Issue 21507 - added precision for function SysTime.toIsoExtString https://github.com/dlang/phobos/pull/8255