Leith Bade

by regenerating the files for each commit 1 by 1, I traced the issue with `160-multiple-parameterized-instance-OK.asn1.+-P_-gen-UPER_-gen-APER_-fcompound-names` to https://github.com/mouse07410/asn1c/pull/103/commits/25e65c01b4b3cf60e5445f4e89338e5fbf654ad4

Made a new PR to fix the tests - https://github.com/mouse07410/asn1c/pull/111

I have this issue too.

I have this this issue too.

Also, as a feature request it would be handy to have a version of `from_time_of_week` and `from_time_of_week` that works on `f64` seconds instead of nanoseconds

It's not urgent, I was able to work around it by just subtracting the 19 second offset to value I give to `from_time_of_week`

Possibly related to this bug, if you provide the same time in two different GNSS timescales you get the wrong values in UTC. For example if I use GPST and...

Yes GPS is 19 seconds offset from TAI, and BDT is 33 seconds.

We had this issue too.

This would also be useful for using `syn` crate to manipulate the generated bindings to implement custom traits and such for generated types.