Replaces github.com/pkg/errors, which is now marked as archived and no longer maintained on github, with native >=go1.13 standard library functions. This preserves the error wrapping previously handled via errors.Wrap via the new %w directive in fmt.Errorf.

This makes the minimum go version go1.13, so thus update the go.mod to reflect and also updates the test matrix here to test from go1.13-go1.18 inclusive (previously tested go1.14-go1.15).

Apparently our tests did not include a case where there were multiple verbatim sections in a pattern, which made us oblivious to this issue. Moving the verbatim value inside the loop does the trick.

In #7 we got a request to add %L as a specification to generate textual representation of milliseconds from the given time. This in itself is totally fine, except %L is not in POSIX, and implementations differ on the exact pattern to invoke this (e.g. %f or %L).

While #7 just decided that %L was the right choice, I'd like to take this opportunity and introduce enough flexibility that we can create different flavors of Strftime in the future when the needs arises.

This PR takes the previously static list of specifications, and moves them in a map so that they are more easily configurable. For common specifications, an optional parameter in the various methods can dynamically alter the specification set so that one instance of Strftime can generate a completely different set of text representations if need be.

If in the future we have enough flavors to work with, such as "the pythin strftime" or "the ruby strftime", we could just wrap the objects as:

... = strftime.Python.Format(t)
... = strftime.Ruby.Format(t)
... = strftime.POSIX.Format(t) // current default

And users can more easily navigate through the different implementations.

for i := 0; i < 400; i++ {
		now := time.Now().Unix() + int64(i)*86400
		cWeek := common.GetWeek(now) // cgo

		strfWeek, _ := strftime.Format("%Y%U", time.Unix(now, 0))
		gWeek, _ := strconv.ParseInt(strfWeek, 10, 64)
		if cWeek != int(gWeek) {
			fmt.Println("failed!!!", time.Unix(now, 0).Format("2006.01.02 15:04:05"), cWeek, gWeek)
			break
		}
	}

output: failed!!! 2021.01.01 00:35:27 202052 202100 failed!!! 2021.01.02 00:35:27 202052 202100

But I'm not confident whether %L is a suitable to do it because that one is not supported by POSIX strftime(3). AFAIK, ruby provides %L and python provides %f for that.

This tests back from the version specified in go.mod to current stable.

This should enable detection of any breaking version changes as part of the dependencies update PR.

subtask forked from #28.

Whilst using this library, I found an interesting bug(?) issue(?) to create log file names.

If I use: pattern, _ := strftime.New("/path/test%Y%m%d.log") I get pattern -> "/path/test20191230.log" Awesome.

But. If I use: pattern, _ := strftime.New("/path/test1%Y%m%d.log") I get pattern -> ".log20191230.log" Not awesome.

If I try: pattern, _ := strftime.New("/longer/path/to/see/where/this/leads//test99%Y%m%d.log") I get pattern -> ".log20191230.log" Also not awesome.

This has only started post PR#6 as far as I can tell, as I have an older forked version that does not have this issue.

Am I going mad?

As discussed in issue 25, this is structurally similar to the standard library's AppendFormat method. I also fixed some issues with BenchmarkLestrratCachedWriter which made it look slower than it really was.

Nets about a 15% speedup which is less than I was hoping for, but still worth using in performance-intensive situations. Note the difference in the time output though - FormatBuffer uses about 20% less CPU time in total for the same number of executions, probably due to reduced garbage collection overhead.

[master][~/hound/go/src/github.com/ianwilkes/strftime/bench]$ time gotest . -bench BenchmarkLestrratCachedWriter -benchtime 30000000x
goos: darwin
goarch: amd64
pkg: github.com/lestrrat-go/strftime/bench
cpu: Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
BenchmarkLestrratCachedWriter-8     30000000         390.1 ns/op
PASS
ok    github.com/lestrrat-go/strftime/bench 11.856s
gotest . -bench BenchmarkLestrratCachedWriter -benchtime 30000000x  12.69s user 1.07s system 111% cpu 12.299 total

[master][~/hound/go/src/github.com/ianwilkes/strftime/bench]$ time gotest . -bench BenchmarkLestrratCachedFormatBuffer -benchtime 30000000x
goos: darwin
goarch: amd64
pkg: github.com/lestrrat-go/strftime/bench
cpu: Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
BenchmarkLestrratCachedFormatBuffer-8     30000000         330.3 ns/op
PASS
ok    github.com/lestrrat-go/strftime/bench 10.063s
gotest . -bench BenchmarkLestrratCachedFormatBuffer -benchtime 30000000x  10.49s user 0.62s system 105% cpu 10.517 total

This is purely a performance issue, but a significant one. This library could be much faster if it could be used in a zero-allocation way, writing into a buffer provided by the caller. Today, this array leaks onto the heap because it's passed into Write().

A simple fix would be to keep that array as a field of the Strftime struct, but then this method would be concurrency unsafe. (The io.Writer spec doesn't allow implementations to modify or retain references to the passed slice, so you can get away with re-using that buffer, but obviously not with concurrent use.)

I think a better approach would be an exported version of the internal format method - maybe just implement Append on Strftime. That way, the user can supply the buffer, and allocation only occurs if it's insufficient.

I'm happy to submit a PR if the approach sounds good.

I was writing docs on what strftime specs are supported for a project of mine using this library, so I went to look for where the specs originated. Turns out they're from FreeBSD[1]/macOS[2] strftime(3): the descriptions match word for word, and the lists of specs are the same with a few specs/categories missing here — POSIX locale extensions (%E*, %O*), glibc extensions, %G, %g and %s. I can understand not implementing %G and %g, they're weird (%G for 2019-12-31 => 2020), but %s is trivial and very widely supported and used, so it's a bit strange it has to be added as an extension, seems more like an accidental omission to me.

So what about promoting it to a standard spec? (The extension could of course be kept around for backward compatibility.) It's an easy change, I can submit a PR if you don't feel like spending time on this.

[1] https://www.freebsd.org/cgi/man.cgi?query=strftime&sektion=3 [2] https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/strftime.3.html

go.sum should be checked into VCS as per official documentation at: https://github.com/golang/go/wiki/Modules#releasing-modules-all-versions https://github.com/golang/go/wiki/Modules#should-i-commit-my-gosum-file-as-well-as-my-gomod-file

subtask forked from #28.

Some strftime implementations support non-zero padded numbers.

For example, in Python

>>> from datetime import datetime
>>> datetime.strftime(datetime.now(), '%-d')
'1'

This is documented in glibc's strftime.

Windows has its own set of codes which use # instead of -: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l?redirectedfrom=MSDN&view=vs-2019

Another reference: https://strftime.org/#platforms