#testUtime.py
##By D@CC
#On 2021 E May 19
#Article: 164.html  selectCode 11
#uSD: none

# Micropython on the pico only keeps 7 significant digits.
# But Python 3.7 works on many more e.g. over 13 which allows
# millivolts of accuracy when working with voltages and 
# milliseconds of accuracy when working with Unix times.
#
# When run on the Pi Pico uTime for today is 1.621625e+09
# so these readings and times must be read and stored
# without doing any arithmetic on them.  Any arithmetic 
# acceptshigh-res numbers as input, but only works with 7
# significant digits.
uTime=1621625066.712
uTime1=1621625066.713
DT=uTime1-uTime
print("uTime:",uTime)
print("DT:", DT)
#MicroPython prints out uTime: 1.621625e+09
#                       DT=0.0
# Python3 prints out:
#    uTime: 1621625066.712 and
#    DT: 0.0010001659393310547
# This is a limitation of the Pico hardware and/or MicroPython
# A voltage reading of 999999.999 (multiplied by 1000)
#    is 999999999 .
# MicroPython needs to convert this to scientific notation
# and outputs this as
voltReading=999999.999
print("voltReading:",voltReading)
# prints 1000000.0
# which doesn't have enough precision.
#so these are stored and transfered as
hiResComplex=(999999999+1621625066712j)
print("hiResComplex:",hiResComplex)
# without doing any arithmetic with them in the pico
#running this program on the Pi using Python3
#shows that no resolution is lost.
#hiResComplex: (999999999+1621625066712j)
#
# this illustrates that the Pico MicroPython cannot
#  provide high enough resolution to handle the unix
#  date in integer mode . So it is kept in str mode.
# Once these hi-res numbers are in the Pi: problem solved.
#/testUtime.py