nmea_utils: Added timezone
** UTC timezone is applied when returning the information from datetime.
Fix applied for #100
Coverage increased (+0.002%) to 98.346% when pulling 1cc09faf9cd584b0b3b35ce5d2b134bfbaaf8a64 on barbacbd:fix_utc_timezone into a0d60b62ab2242af7b3a64c415947eb52a3638a5 on Knio:master.
Coverage increased (+0.002%) to 98.346% when pulling 1cc09faf9cd584b0b3b35ce5d2b134bfbaaf8a64 on barbacbd:fix_utc_timezone into a0d60b62ab2242af7b3a64c415947eb52a3638a5 on Knio:master.
Coverage increased (+0.02%) to 98.38% when pulling 95035c30b50af7d91486ca6299fa11e3f1fa7e93 on barbacbd:fix_utc_timezone into 988c297ce82d976db9094b435a1aa290e7d5b9ed on Knio:master.
@Knio Looks like another python incompatibility. I fixed that, so can you give this a once over (or twice) for me?
is there a way to only require the install dep on py2.7, and use datetime.timezone.utc on py3? I don't want to introduce unnecessary 3rd party dependencies
Sure I can do some import "magic" If you want. Some people want to use the same deps for everything and some want what you want. You never know until you try right! I will make that change .
Actually it looks like it was python 2.7, and < 3.6
@Knio hopefully I have what you wanted pushed here. May need to rerun the tests as I pushed something prematurely earlier. The tests pass in 2.7, 3.6, and 3.8 on my system .
@Knio is this one good to go or do you need more changes ?
@Knio can we close this one or merge or other haha? I have it still sitting in my queue
@Knio this has conflicts with the main branch. Looks like you may have added something similar. Is this safe to close ?
Hey, yes I did. Are you able to confirm if what's in master solves the problem for you?
Should work for me.