pax: Ustar MTIME header field is too small

I have some files that have timestamps outside the range of the traditional
32-bit unix timestamp. As I understand it, the standardized pax enhancements
the ustar format specifically allow for this, using extended attributes that
store the timestamps as decimal numbers as UTF-8 text. It appears that our pax
does not support generating pax output with these extended attributes. (In
fact, it doesn't support a '-x pax' output option, which I note that some other
pax implementations do.)
The following test case demonstrates the problem:
netbsd$ touch -t 192001251150 foo
netbsd$ ls -l foo
-rw-r--r-- 1 gadams wheel 0 Jan 25 1920 foo
netbsd$ pax -w foo > foo.pax
pax: Ustar MTIME header field is too small for foo
zsh: 5847 exit 1 pax -w foo > foo.pax
And the produced archive is simply 10240 bytes of 0x0.
What's very interesting, however, is that I can create a pax archive on an
OpenSolaris machine containing that file and expand it successfully on NetBSD,
and the date is maintained:
os$ touch -t 192001251150 bar
os$ pax -w bar > bar.pax
( copy pax file to NetBSD machine )
netbsd$ pax -r -pe < ~/bar.pax
netbsd$ ls -l bar
-rw-r--r-- 1 gadams wheel 0 Jan 25 1920 bar
So, our pax supports reading the extended attributes, but refuses to produce
them. The version from pkgsrc (which I assume would be as up-to-date as the
latest -current) behaves identically. Is this a known behavior? Should I look
into adding support? (I haven't really cracked the code open, yet.) As a quick
solution to my immediate need, should I just look into finding and building
some third-party pax?
(Side note: I'm trying to move these files from a NetBSD machine to an
OpenSolaris machine. Our ffs dump format is not compatible with Solaris's
ufsrestore, so that leaves archive programs like tar/pax. NFS, at least v3,
can't handle these dates either. Nor can the cpio formats pax supports. Are
there are other options?)
Thanks,
- Geoff