Question: How to convert time zone string input into NodaTime types?

[Kavignon]

I'm a NodaTime newcomer with a question. Is it possible to convert a time zone provided as a string (ex: "UTC + 4") and convert it to a NodaTime type? I'm looking at the documentation and I can't find my way around. Any help would be greatly appreciated, even if it's just pointing me in the right direction!

Thanks in advance

[jskeet]

"UTC+4" isn't really a time zone - it's an offset. (It says that the given date/time is 4 hours ahead of UTC, but says nothing about what the time will be two minutes later, for example.)

That concept is represented by the Offset type in NodaTime, and it can be parsed with the OffsetPattern type. You'd need to work out exactly what strings you want to be able to parse though - for example, do you want to be able to parse "UTC + 5:30"? Is there actually a space between the "+" and the numbers?

[Kavignon]

Maybe providing context could be helpful here.

I am in charge of the mentorship program for the F# software foundation. As we received applications, we asked for mentors and mentees to provide us with what I thought was a timezone but is actually an offset from the UTC.

With the data that I have based on the applications, I'm trying to build automation capable of matching mentors to mentees by checking not only if their interests are alined but also their time zone.

If the concept of space in the data is wrong, I can do a cleaning step on my data to remove it.

My data would look like this in my csv document:
UTC + 10

Another question I would have for you concerning NodaTime would be how can I make sure, as I'm matching mentors to mentees, that I can consider the daylight saving time for matches? My goal here isn't to find exact matches because that could be very difficult. It'd be best if I can find some sort of overlap in between availabilities. When I do find them, I want to make sure I can consider daylight saving time to avoid any complexities down the road for the duos I'll create.

Thanks @jskeet for helping me!

[jskeet]

That's unfortunate - it would have been much better to ask for actual time zones. In particular, you've asked for the current offset, which may not be the offset by the time you're actually trying to arrange things :(

Another question I would have for you concerning NodaTime would be how can I make sure, as I'm matching mentors to mentees, that I can consider the daylight saving time for matches?

You can't, precisely because you've not asked for a time zone. Two people in different time zones can have the same UTC offset right now, but a different offset in a month. If you had the actual time zones, it would be easy to work out what the local time would be for each of the people involved.

I suspect the best approach now would be to go back to everyone and ask them for their actual time zone. Sorry to be the bearer of bad news.

[Kavignon]

Since I'm a bit short in time, I can't reach everyone before the mentorship starts, I could work with the offset and make an educated guess about whether or not the matches work. That's how it's been done before.

I understand it's not the best way, but I can make do for now with this. Since my automation is not only for this round but also for other mentorship rounds, I can fine-tune it later on. Say I update the form and request the timezone instead of the UTC offset, what would be my next steps?

Which API would make the most sense for me and what would you recommend as for date & time logic to support both DST and standard time?

[jskeet]

Say I update the form and request the timezone instead of the UTC offset, what would be my next steps?

Working with a mixture of "some offset data and some time zones" would be tricky. You might want to just take an educated guess at the time zone of each user based on their response, and update the data to that - ideally allowing them to edit in the future.

Which API would make the most sense for me and what would you recommend as for date & time logic to support both DST and standard time?

Well once you've got a time zone ID, you can get a DateTimeZone and work with that. I'm afraid I can't be more specific than that without knowing exactly what you want to do. But you should look at the conversions between ZonedDateTime and LocalDateTime as a starting point, probably.

[Kavignon]

Sorry for the late reply @jskeet! Like I mentioned previously, I was trying to generate pairings automatically of mentors and students for the F# mentorship program that I'm leading. I managed to hack together a decent implementation with TimeSpan since all I had were the UTC offsets. Starting the newest iteration of the mentorship program, I can start asking for the time zone IDs as you mentioned before.

With the time zone and the availabilities of the mentors and the students, I was trying to create in the background a schedule and see where it could overlap. When a match was found with that and for their interests, a potential match became viable in the eyes of my tool.

https://github.com/Kavignon/FSharp-Mentorship-Automatic-Planner

Thanks for clarifying timezone issues to me. I appreciate that!

[jskeet]

Okay, it sounds like we're sorted now - I'll close this issue.