class time_zone persistence

[JeffAbrahamson]

Is it worth noting how a class time_zone could / should be persisted? Perhaps this is more appropriate for a header file in the code, however, than for the draft standard document.

The niggly detail is the template parameter D.

[devjgm]

I would say that there's nothing to persist about class time_zone. The data is loaded from disk or some other persistent medium. The only thing to persist is the name of the time zone.

Do you have a specific use-case in mind that I'm misunderstanding?

[JeffAbrahamson]

I do have a use case.

I have a applications that receives civil dates with timezones. For computation, we generally want to store and use the absolute time expressed in seconds since the epoch. For display, we sometimes like to map to a civil time (for example, displaying events by when a human would have perceived them happening, e.g., "in the morning").

In one DIY version, we simply parse and store the reported date components and/or the UTC offset.

It seems more correct to store some concept of timezone so that the absolute time plus this extra bit of information can reconstitute a civil time. In any case, I'd much prefer to get this information directly from the cctz civil time parser than reparsing it myself.

[devjgm]

Ideally you would persist the time zone using its string name, e.g., "America/New_York". That's really the right way to do it. Then you would use that string to load a TimeZone object like normal. Can you not do this in your application?

[JeffAbrahamson]

Sometimes all I have is the civil time I'm given, e.g., "2016-02-27T22:32:25+08:00". That's vague -- maybe there is more than one valid timezone at that offset. But sometimes it's the best I can do. (Maybe I know some geographical information about where the time came from, but using that is surely out of scope for cctz.) So I say

const char kTimeFormat[] = "%Y-%m-%dT%H:%M:%E*S%Ez";    // ISO 8601.
if(! cctz::Parse(kTimeFormat, date_str, utc, &this_time_point)) ... ;
system_clock::to_time_t(this_time_point);

and I get absolute time in the format I want. But now I manually parse out the time offset, which seems odd to me, since cctz is already parsing that data.

What I'd like (and I realize here that I gave this issue a bad title) is an optional extra argument to cctz::Parse that could give me access to the parsed structure (in my case, the offset). Said differently, what I'd really like is that when I parse an ISO 8601 time and get an absolute time, that I could recover enough information to reproduce a civil time that humans would mostly agree represents the same time as the input civil time.

[devjgm]

That make sense. Keep in mind that the offset you parse (+08:00 in the example above) is not a "time zone". It is a UTC offset, but that's different from a time zone. That UTC offset is valid only for the specific time instant from which it was parsed.

Also, a pedantic note about terminology. The time string from your example, "2016-02-27T22:32:25+08:00", actually represents an absolute time. The string itself contains a civil time (the YYYY-MM-DDThh:mm:ss part) AND a UTC offset. Both of those taken together are an "absolute time". See https://docs.google.com/presentation/d/1H1tkvg_vm39jXPZbOvQLoWb32POSpTYiZx8qMtBvdSQ/pub?start=false&loop=false&delayms=3000&slide=id.gdfa6eb1a1_5_147

---

OK, sorry for that digression. I agree with your request. It would be useful for cctz to be able return to you the UTC offset that was used to build the returned absolute time. We have already been thinking about how best to express this in the API. I believe it is something we want to do.

Would you please file this feature request as an issue against https://github.com/google/cctz so that we can track it and do not forget it? It's also useful to see that there is demand from real users for this. Thank you.

[JeffAbrahamson]

For future readers of this issue, I think this issue #4 and issue google/cctz#16 represent the same issue. I don't remember precisely why they both exist nor why google/cctz#16 seems to predate this even though I think it is a response to @devjgm's request that I file a separate issue there.