Home/ Questions/Q 8794757
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T23:17:41+00:00

The project I work on is basically a data collector. By way of orientation,

  • 0

The project I work on is basically a data collector. By way of orientation, it may help to think of it as Wireshark (or equivalent) with parsing/analysis capabilities of the Application layer (OSI Layer 7). The current version is a legacy MFC application with 15+ years under its belt. It still works, but maintenance, stability, and scalability are real concerns that we are facing. The project leadership team has recently agreed that we need to begin developing the next generation of the product, and we are targeting .NET as the product is strictly a Windows desktop-based product.

Given that our users routinely analyze log files collected literally around the world, message timestamping is very important. The current product uses _ftime_s() to assign a timestamp, and I had assumed we would simply use System.DateTime.UtcNow to get timestamps in the future on the .NET side. That is, until I read about noda-time. Now, I’m thinking that our problem domain requires more care concerning time-related functionality than I had ever cared to consider.

So a few questions.

  1. From the description I’ve provided above, does it make sense to incorporate noda-time using NodaTime.Instant for timestamping?

  2. Given a choice, I’d much prefer to pay for dedicated support than use an open-source project for fear (paranoia?) that the project is abandoned. Any thoughts or guidance on this point from those more inclined to embrace the open-source philosophy?

  3. noda-time is currently in its 2nd beta. Is there a target date for NodaTime 1.0.0?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    1. As Matt says, you could easily just use DateTimeOffset to represent an instant in time. I’d argue it’s not as clear as using Instant, in that it suggests you might actually be interested in a local time and an offset, rather than it really just being a timestamp – but if this is the only reason you’d use Noda Time, it would make sense to stick with DateTimeOffset.

    2. This is a reasonable fear, but you have my personal word that I’m not about to abandon Noda Time. Of course, the reverse argument is that if I did abandon it, you’d still be able to patch it – whereas if you used a commercial product and the company folded, you’d be stuck 🙂 I do understand the concern though.

    3. As it happens, I’m hoping to release v1.0.0 today 🙂

    • 0