My reason for wanting to use Period and ZonedDateTime

13 views
Skip to first unread message

Tim Yorke

unread,
Jul 1, 2024, 10:14:12 AM (3 days ago) Jul 1
to Noda Time
Hi there, thanks for this great library - a breath of fresh air coming from System.DateTime. 

Your documentation mentions that you'd like to hear from anyone wanting to add a Period instance to an Instant, or ZonedDateTime, so here I am. 

My SW stores all of its times as UTC and I'd like to use type-safety to enforce that the timestamps I accept really are in UTC, which leads me to using Instant everywhere. However, I'd also like to take a timestamp and add a month to it (so 1/1/2000 00:00Z would become 1/2/2000 00:00Z). 
Now I appreciate that Instant has no concept of months, but it seems I can't even convert it to a ZonedDateTime (via InUtc()), I have to convert it again to LocalDateTime, add the month, then back to ZonedDateTime and then back to an Instant. It makes me feel like I'm missing something or mis-using Instant.

Not a roadblock at all, but I suppose ideally I'm looking for a strongly-typed UTC datetime type, that supports Period arithmetic.

Thanks again,
Tim

Jon Skeet

unread,
Jul 1, 2024, 1:18:46 PM (3 days ago) Jul 1
to noda...@googlegroups.com
I'd say that the very notion of "adding a month to an Instant" is where you're potentially misusing Instant, given that Instant is meant to be calendar-neutral (and time-zone neutral).

I strongly suspect that you'll get a more consistent and predictable experience if you always add some fixed duration - e.g. 30 * 24-hour-days - instead of a month. Otherwise any user who doesn't understand that everything is stored in UTC may get quite confused by the behaviour, particularly around month start/end dates if they're actually operating in a time zone which puts the current UTC instant in a different month to their local one.

But if definitely want to do this, you could at least reasonably easily add an extension method:

public static Instant PlusPeriod(this Instant start, Period period) =>
    start.InUtc().LocalDateTime.Plus(period).InUtc().ToInstant();

You only need to write that once. I wouldn't want to put it into Noda Time because as I say, I think it's really not a logical operation - but it should work just fine, if that's definitely the operation you want to execute.


--

---
You received this message because you are subscribed to the Google Groups "Noda Time" group.
To unsubscribe from this group and stop receiving emails from it, send an email to noda-time+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/noda-time/422421a0-37a0-4800-afa9-c263e7ce9030n%40googlegroups.com.

Tim Yorke

unread,
Jul 1, 2024, 2:37:35 PM (3 days ago) Jul 1
to Noda Time
Thanks for the advice - I'll go ahead and add that extension method.

Just to give you the full picture, and to demonstrate the motivation, I'm developing some trading software, and technical analysis of the markets has a very strong tradition of using second-based intervals (1min, 5min, 15min, 1hr, 4hr, 1D up to 1W) and then monthly-based intervals (1M, 3M,  6M, 1Y etc) as the basis for representing the data e.g. candlesticks, and all of that trading data is stored as UTC (well Instants in my case).  

Reply all
Reply to author
Forward
0 new messages