Store a timezone

[JeffAbrahamson]

This may be a question about how to use the library rather than an issue. If so, many thanks for a pointer in the right direction.

I receive strings representing time and then store absolute time (in protobufs as int64):

// Time zone is required by cctz::Parse().  It is only used if the
// formatted time does not include offset info.
const auto utc = cctz::UTCTimeZone();
const char kFmt[] = "%Y-%m-%dT%H:%M:%E*S%Ez";
system_clock::time_point this_time_point;
if (!cctz::Parse(kFmt, date_str, utc, &this_time_point)) {
    cout << "Failed to parse time: " << date_str << endl;
    return 0;
}
return system_clock::to_time_t(this_time_point);

This works great. From time to time, I need to know local time for the original source. That is, I've received something like 2015-12-23 10:55:09+0100 and stored 1450864509. Now, in another process on another day, I see 1450864509 and want to recover 10:55 (i.e., for this absolute time, the corresponding local time was 10:55. For a concrete mental image, suppose I'm analysing when events correspond to lunchtime.

Of course, I can (outside of cctz) parse out the UTC offset and store that. I could also simply parse out the "HH:MM" string and store that. But those both seem quite wrong, and cctz seems well enough thought through that I'm guessing there's some way I haven't understood to persist an idea of a timezone.

And, if not, I suggest that this would be useful.

[devjgm]

Hi. That's actually a feature that we should be adding shortly. I already
have a patch that returns the time zone offset that was found when parsing.
Look for something to address this early in the new year. Thanks.

On Wed, Dec 23, 2015, 5:02 AM Jeff Abrahamson [email protected]
wrote:

This may be a question about how to use the library rather than an issue.
If so, many thanks for a pointer in the right direction.

I receive strings representing time and then store absolute time (in
protobufs as int64):

// Time zone is required by cctz::Parse(). It is only used if the
// formatted time does not include offset info.
const auto utc = cctz::UTCTimeZone();
const char kFmt[] = "%Y-%m-%dT%H:%M:%E*S%Ez";
system_clock::time_point this_time_point;
if (!cctz::Parse(kFmt, date_str, utc, &this_time_point)) {
cout << "Failed to parse time: " << date_str << endl;
return 0;
}
return system_clock::to_time_t(this_time_point);

This works great. From time to time, I need to know local time for the
original source. That is, I've received something like 2015-12-23
10:55:09+0100 and stored 1450864509. Now, in another process on another
day, I see 1450864509 and want to recover 10:55 (i.e., for this absolute
time, the corresponding local time was 10:55. For a concrete mental image,
suppose I'm analysing when events correspond to lunchtime.

Of course, I can (outside of cctz) parse out the UTC offset and store
that. I could also simply parse out the "HH:MM" string and store that. But
those both seem quite wrong, and cctz seems well enough thought through
that I'm guessing there's some way I haven't understood to persist an idea
of a timezone.

And, if not, I suggest that this would be useful.

—
Reply to this email directly or view it on GitHub
#16.

[JeffAbrahamson]

Is the patch stable enough that it could be pushed to a branch for testing/review?

[devjgm]

Hi, Jeff. Sorry for the delay. We're still debating internally about the best way to return this data in the cctz API. We're hesitant to return the raw offset because that encourages bad practices like doing arithmetic with that offset. We're also a little hesitant to return the offset wrapped in a cctz::TimeZone because it may be confusing that it's not really a complete time zone that was returned, it's just a fixed UTC offset and is only necessarily applicable to the specific time instant that was parsed.

So we are investigating a few other alternatives. We are interested in finding a way to return all the data from the input string (e.g., 2015-12-23 10:55:09+0100) to the caller in a convenient form.

Thanks for your patience.

[JeffAbrahamson]

Is this (internal) discussion happening in the light of day?

[devjgm]

The majority of the discussion is happening with respect to Google's internal code and our internal copy of cctz. Those discussions are not externally visible.

[JeffAbrahamson]

What I was trying to poke you about was suggesting that maybe, in so much as there exists this open source version of cctz, it might be worth posting regular summaries of your conversations on issues, assuming there are reasons not to make the full discussion open.

[devjgm]

I understand. We'll do our best to keep this thread updated.

[udovin]

Are there any updates here?

[devbww]

Are there any updates here?

I believe the answer is no. If you want to take a string like "2015-12-23 10:55:09+0100" and extract the "+0100" part, you're on your own. Timezone offsets are not first-class objects in CCTZ (fixed_time_zone() notwithstanding) by design.

From time to time, I need to know local time for the original source. That is, I've received something like 2015-12-23 10:55:09+0100 and stored 1450864509. Now, in another process on another day, I see 1450864509 and want to recover 10:55

My answer to the original question would be to not discard information that you later need. That is, if you need the local time, store the local time.