make much more flexible

[bewest]

• Able to express times in local zone.
• Able to shift time to another zone correctly.
• Can select and transform multiple date fields at the same time.
• Introduces/demos new feature of openaps to ease how uses store and retrieve
  their configuration from config.
• Can save timezone (or None), as well as list of date fields.

[bewest]

Examples uses:

  645  openaps use tz -h
  646  openaps use tz clock -h
  647  openaps use tz clock monitor/clock.json 
  652  openaps use tz convert 01.prepare/mm-resolved.json 
  653  openaps use tz rezone 01.prepare/mm-resolved.json 
  654  openaps use tz rezone monitor/glucose.json 
  655  openaps use tz rezone monitor//pump-history.json 
  658  openaps use tz rezone monitor/pump-history.json 
  659  cat monitor/pump-history.json | openaps use tz rezone  -
  668  cat monitor/pump-history.json | openaps use tz rezone  -h
  670  cat monitor/pump-history.json | openaps use tz rezone  -h
  671  cat monitor/pump-history.json | openaps use tz rezone  
  672  cat monitor/pump-history.json | openaps use tz rezone  -
  683  cat monitor/pump-history.json | openaps use tz rezone  -
  698  openaps use tz rezone monitor/pump-history.json 
  725  openaps use tz rezone monitor/pump-history.json 
  726  openaps use tz rezone 01.prepare/mm-resolved.json 
  785  openaps use tz rezone --astimeonze 01.prepare/predicted.json 
  786  openaps use tz rezone --astimezone 01.prepare/predicted.json 
  787  openaps use tz rezone  --replace 01.prepare/predicted.json 
  788  openaps use tz rezone  --adjust replace 01.prepare/predicted.json 
  789  openaps use tz rezone  --astimezone 01.prepare/predicted.json 
  790  openaps use tz rezone   01.prepare/predicted.json 
  791  openaps use tz rezone --astimezone 01.prepare/predicted.json 
  792  openaps use tz rezone  01.prepare/predicted.json 
  793  openaps use tz rezone  --astimezoone 01.prepare/predicted.json 
  794  openaps use tz rezone  --astimezone 01.prepare/predicted.json 
  800  openaps use tz rezone  --astimezone 01.prepare/predicted.json 
  801  openaps use tz rezone  --astimezone 01.prepare/mm-resolved-zoned.json  
  805  openaps use tz rezone  --astimezone 01.prepare/predicted.json 
  813  openaps use tz rezone  --astimezone 01.prepare/mm-resolved.json 
  815  openaps use tz rezone  --astimezone 01.prepare/mm-resolved.json 
  827  cat 01.prepare/predicted.json | openaps use tz rezone --astimezone -
  843  history | grep 'use tz'

[bewest]

This replaces the timezone, such that the "datetime" expressed is now in this new timezone rather than the old one.

When a datetime that does not know about a timezone gains the ability to reason about timezones, calling isoformat( ) on the object will result in the similar behavior as javascript's dt.toISOString( ): the date will be rendered as iso 8601, in Zulu/UTC timezone, with the hours shifted from the local timezone appropriately. The inverse happens with parsing a zone-aware iso8601 string: the parser determines the difference between your local time and the described zone, and produces the correct wall-time as a result. By default, printing it out again will shift it back to the "canonical" Zulu/UTC zone-aware representation. While the tools heavily prefer UTC/Zulu time, it can be useful to print iso8601 date strings with the local time correctly described locally.

The following dt.astimezone line, in contrast, "shifts" the hours from timezone A to timezone B appropriately while pinning the behavior of isoformat( ) to produce an iso8601 format in the new timezone (not Zulu/UTC). This can be useful in printing a valid zone-aware 8601 string in the local time, given a valid is8601 datetime that is already (correctly) zone aware in another zone, or missing a zone altogether.

These two behaviors can be invoked by the tool independently, to control whether or not to shift times vs simply printing them in local time vs UTC time.