What use cases do/might you have for getting the system's UTC offset directly?

Hello! Author of the time crate here. I'm looking to add the ability to obtain the local UTC offset. However, I'm having a hard time thinking of use cases to get access to that info directly. The only instance I can think it would be relevant is for display/formatting. Pretty much every other case, it would be more idiomatic to perform all calculations using UTC.

If you have a use case, speak up! Now's your chance. I could very well be missing something obvious. If there isn't a convincing use case to access the offset directly, there won't be a method for it. Of course, it would still be possible to hack your way around it, but that's not really the point.

Shameless plug: feel free to help out if you're familiar with OS APIs. Safety checks are always appreciated :slightly_smiling_face:

Signing off for now. I'll be back tomorrow to check in.

git timestamps, as stored in commits, are pairs of UTC time and a time zone offset.

I'm not sure that it is a common use case, and I can't say I've needed it myself, but what about calculating time offset differences? For example, if you had a world clock app or calendar app and wanted to show the time difference between the local time and another time.

Looking into this case specifically. I think it would be solvable by the way things get serialized. In a 0.3 release I'll almost certainly end up including the offset of the UtcOffset in the serialized value, which would alleviate that concern.

You'd still be able to do elsewhere.time() - here.time(), which would return a Duration. That would also ensure that you're getting the sign right, where methods would have to be a bit more verbose for clarity.

I stopped using time a long time ago and am a contributor to chrono, but I heard you picked up development of time once more - congratulations.

I think what you're asking about is use cases that lie in the junction between a naive time (e.g. an alarm for "6:00 am") and a full-blown, offset-aware datetime object (a typical timestamp). Unless I'm missing something, you would need it in order to do any sort of grouping in a native app by naive date, e.g. I wouldn't be able to show a user their orders by "day" in their local timezone if I couldn't get their offset (by, e.g., executing a database query that explicitly included or used the offset to compare against UTC-stored values in the db).

You would also need it to perform any sort of time-based introspection; for example, to recreate GitHub's "commit activity" punchcard or any other histogram trying to break down data by naive day or time values. If I am in Chicago today and I perform some action at 6pm, but tomorrow I am in London and do something else at 6pm, a graph should certainly not be created based off of the UTC timestamps but rather the naive day/time.

In a completely different context, imagine embedded development for, say, a fitness tracker. You specify a typical day starts at 6am. If you're walking at 1am, I should show you the tally of steps taken starting the previous calendar day, not an hour ago (because your new "day" has not yet started, you're just having a very long "today"). You can't do that if you only have an opaque timestamp.

This is certainly one of the more convincing use cases, as even using .time() likely wouldn't suffice here — it's plausible you'd want to show differences based on the time zone.

Between the responses here and on Reddit, I've seen enough plausible cases that I'll be exposing the API :slightly_smiling_face:

If I'm understanding correctly, the question is, when would you need the offset of the local timezone from UTC.

Consider the case where you have log data that was generated locally in the local timzone, without any indication of that time zome. Http server logs for instance. Or debug logs from an application.

You might think that all you need to do is assign a time zone, and let the libraries do the conversion. But if there are any big risks involved, you might also want to report the time zone offset so that the user can double check the validity of the conversions.

That might seem pedantic to some, but in my experience, any time there is time zone conversion happening, there's a chance for a mistake, and if the risks are great, it's valuable to catch it early.

Closed by request of the topic creator.