How do you infer time zone name from timestamp strings with only offsets?

[bionicles]

Suppose we have a timestamp like

"2019-01-30T10:33:38.186520297-05:00"

How can we convert this to Zoned if we don't necessarily know if the IANA time zone name is America/New_York or America/Chicago ?

I'm assuming there are only small numbers of times where it's ambiguous (right around the changing of daylight savings time)

Would it be possible to pass a list of options as an argument to a function, and if exactly one of the options matches that offset on that date, use that?

My workaround is to push "[UTC]" onto the string and parsing it to Zoned, and just work with UTC for everything, but then we're losing local source offset information, and sometimes this changes the dates, which could be problematic in cases where API owners pass dates as datetimes at midnight (quite common).

I realize it's impossible to cover all edge cases, but what would be the best practice to parse datetimes with offsets but missing / unknown time zone names? (I did already email the source API owner to request they add [{tz}])

[BurntSushi]

Good question.

Someone else asked a very similar question (if not identical) here: #112 (comment)

I then forwarded this question to the Temporal folks (from which this behavior of Jiff was inspired): tc39/proposal-temporal#2930

Basically, Jiff should probably provide some way to extract the offset here or some way to produce a Zoned with a TimeZone::fixed. It's just important that it doesn't happen by default (that is, requires an opt-in) because it's a footgun. It's not totally clear if this would work for you though. Since while it would be Zoned, it wouldn't really have a time zone attached to it. Just a fixed offset that will never get DST arithmetic correct.

One thing that came out of the conversation above was that it would be good to better understand the use case. Since you have a timestamp without any knowledge of what time zone it's in, why do you want to keep the offset around? As in, why do you see using UTC (or even just a Timestamp instead of Zoned) as a work-around? What do you need from Zoned here? (This is me trying to better understand what you're trying to do.)

Would it be possible to pass a list of options as an argument to a function, and if exactly one of the options matches that offset on that date, use that?

Can you give an example of how this might work?

[bionicles]

Presumably the API owners just didn't know to follow the format with the time zone name in brackets. Many developers are still figuring out time zones. It seems like they assume offsets are enough, but they're not [always] enough.

In some cases, we have partial knowledge of the time zone, along with an offset. This is financial timeseries data which is usually either New York or Chicago, so for an example, if we could pass a datetime string with only an offset like ("2019-01-30T10:33:38.186520297-05:00", &["America/New_York", "America/Chicago"]) to some function, and we know if it's -5 offset, there are two Ok(zdt) options:

If the civil date and time do not fall during daylight savings time, then we know from our list of two time zones it must be EST offset in America/New_York which is -5 (https://en.wikipedia.org/wiki/Eastern_Time_Zone ... common for stocks);

Conversely, if the civil date and time falls during daylight savings time, then the -5 must mean in America/Chicago (https://en.wikipedia.org/wiki/Central_Time_Zone ... common for options, bond yields, some indices)

since this date is 01 30, it's the end of january, not in daylight savings time, so it must be America/New_York during EST with a -5 offset, and America/Chicago has a -6 offset then, couldn't be Chicago time.

if the date were in the summer, like 07 04, then we'd know it's during daylight savings time, and then America/New_York has a -4 offset, but America/Chicago has a -5 offset in the summer, so we would know a summer timestamp with a -5 offset would be CDT, and couldn't be New York time

i'm not sure what to do in daylight savings leap hour moments where the offset may be ambiguous, in those cases raising an error could be good, but realistically that's one or two hours all year, some way to attempt to handle cases where we don't have a time zone name but we do have a ISO-8601 string with an offset, and we know it must fall in one of a small number of specific time zone names, would be epic, because sometimes we only have a couple of distinct options for the time zone name and it could theoretically be fixable using a lookup table of offsets per timezone on various ranges of civil dates and times.

Zoned is my main go-to timestamp type, it's the most precise thing and way better / more usable than chrono (you rock!), so i have various inputs that i'd like to map onto Zoned, and the only problem is these various API data sources don't always write the zoned datetimes in the proper string format.

Presumably, the world will switch from just writing offsets and always include time zone names, but until it does (and to help with that transition) a nice story for the offset-only case could be useful, because there's gotta be a billion timestamps out there which are missing the [{time_zone_name}] part

The proper principled approach is to know the time zone name, and add it onto the timestamp strings:

        dt.push_str(&format!("[{time_zone_name}]"));
        let zdt = dt.parse::<Zoned>()?;

That's what I've been working on today, getting / caching time zone names for various time series. Sorry for writing a lot, thank you for your responsiveness

[BurntSushi]

Thank you, that's helpful!

I'll be publishing a new jiff::fmt::temporal::Pieces API soon that will let you parse a datetime string into its individual components. And then from there, you should be able to implement the logic you want here. I don't think Jiff will offer a high level function for you to "guess" the time zone because it seems like something more suited to a bespoke implementation that has context built into it for disambiguating and litigating corner cases.

[BurntSushi]

All righty, I've published jiff 0.1.20 which has the new jiff::fmt::temporal::Pieces type in it. It doesn't provide the high level function you want, but I wrote a case study on how to approach the problem with example code. Let me know if that helps!