A couple of points:
Avoid using
DateTime.Now
- It's already translated to the local time zone, so during DST fall-back transitions the result can be ambiguous.
- If you need to get an exact unambiguous moment in time without using Noda Time, then use
DateTime.UtcNow
. - You could also use
DateTimeOffset.UtcNow
, orDateTimeOffset.Now
. When the offset is included, there is no ambiguity. - See also The Case Against DateTime.Now on my blog.
In Noda Time, realize that
SystemClock.Instance
is an implementation of theIClock
interface. Whenever possible, you should code against the interface, such that you can replace the implementation in your unit tests if desired. Though in the simplest of examples, there's nothing wrong with callingSystemClock.Instance.Now
, it just isn't as testable.As far as which time zone input to use, that is entirely based on your application requirements.
If you can depend on the system to be set to the correct zone, you can retrieve it with
DateTimeZone tz = DateTimeZoneProviders.Tzdb.GetSystemDefault();
If you can't depend on the system time zone to be set correctly, you might consider some other source of input.
You mentioned GPS coordinates. If you have that, perhaps from a mobile device, there are solutions for resolving it to a time zone. See here for some options. Noda Time can't help you in this regard.
You might also consider asking the user of your app to pick a time zone from either a drop-down list or a map. There are some map-based time zone pickers for HTML/JS here and here. (I am unsure if they will work in a WinJS based Windows Store App or not, and I don't know of any XAML based solutions off hand.)
If the actual time of their clock is set wrong, there's not a lot you can do, other than try to reach out to another server to retrieve a time stamp. In most cases, you should rely on the operating system to already be synchronized with a time server.
If you do require synchronization with an external service, that can be challenging. You need something that implements NTP properly, including measuring and compensating for transmission delay. That's not easy, and probably requires an external library. I don't know of one off-hand to recommend.
Reaching out to a web service and returning the current time isn't necessarily going to be as accurate as you might think, as that does not compensate for the time it takes for the server to transmit that response to you.
If you are running on a device with a GPS receiver, then it is technically possible that it can provide an accurate time stamp received from the GPS signal. Whether or not that is retrievable and usable via the Windows Store API, I am not sure. I checked a few references on MSDN but came up empty.
Regarding the two code samples you provided, they're doing slightly different things, but go with option 2. It's much cleaner, and is pure Noda Time.