-
Notifications
You must be signed in to change notification settings - Fork 2
Description
DateTime is serializable, so we could just get the DateTime from the debuggee side and perform all calculations on the debugger side. However, it is possible to use VS for debugging on a different machine, which may be in a different zone; the resolution of an Instant from a DateTimeKind of Local or Unspecified (or a DateTimeKind of Utc which is treated as Local) needs to be done on the debuggee side.
We also need to determine what the zone is on the debuggee side, as it might be different from on the debugger side.
Could the zone id (the TZDB; probably not the BCL) returned from the debuggee side, not be available on the debugger side?
- Different versions of NodaTime. Presumably, later versions are backwards-compatible with earlier versions, at least WRT the TZDB info, so the versions we're currently injecting (debugger: NodaTime 3.0.0, debuggee: 3.0.0 where possible, fall back to 2.4.1) should work. If the debuggee already references a later version of NodaTime before injection, that might be a problem.
- TZDB updates independent of NodaTime. If we've injected NodaTime into the debuggee, there isn't any code that will make use of the updated TZDB info. Again, if the debuggee already is using NodaTime, and is using the custom updated data, it might be a problem.
I'm not sure if there's anything we can do to resolve this, other than making sure the visualizer always uses the latest NodaTime version possible on both the debugger and debuggee sides. Doing so would make it better, but not cover all possible cases.