Example DST dates incorrect about cctz HOT 10 CLOSED

Hi Matt,

Thanks for taking a look at cctz.

If you try out the example, I believe you will find that the description is accurate.

The "pre" time_point for a SKIPPED civil time is always what the actual time would be if you forgot to adjust your time-of-day clock over a transition. That is, if you ask for "2011-03-13 02:15:00 America/Los_Angeles", then the "pre" time_point will be 15 minutes after the transition, or "2011-03-13 03:15:00 -0700".

Conversely the "post" time_point will be 45 minutes before the transition, or "2011-03-13 01:15:00 -0800". It is always as if you adjusted your time-of-day clock early.

As for the transition time, the "trans" field is an absolute time, and in this case the rendering of that time in America/Los_Angeles must be "2011-03-13 03:00:00 -0700". People can say whatever they like, but a clock would never display "2011-03-13 02:00:00 -0800".

I hope that helps.

Bradley

from cctz.

Just a quick followup, I guess the important point is that "pre" does not mean that the time_point occurs before the transition, but rather that it utilizes the pre-transition UTC offset. I admit that it is confusing at first, but we could not think of better names. Alternate naming suggestions are welcome.

from cctz.

Sorry, but I'm still not understanding your explanation.

If I simply forgot to adjust my clock, then asking for 2:15 I'd actually get back 02:15 -08:00. The time wouldn't be invalid if the clock wasn't adjusted.

Likewise, if I adjusted my clock early, (say for example, at midnight I skipped forward to 1:00), then asking for 2:15 I would get 2:15 - 07:00 - which would of course be the wrong instant in time.

Then you said that pre means that it uses the pre-transition offset, but in the spring, the pre-transition UTC offset for Pacific Time is -0800. After the transition, it's -0700. That's the opposite from what you stated.

The intention is good here, and I'm sure the API is solid, I'm just not understanding the intended interpretation of the output.

from cctz.

BTW - I understand about the trans behavior, and that's fine as long as it's documented. Also, the examples given for the fall-back transition seems reasonable. It's just the spring one that I'm having trouble comprehending. It seems as if you wanted spring and fall to be opposites - but time only moves in one direction. 😄

from cctz.

Hi Matt,

The misunderstanding might just be a question of labeling. For example, you said:

If I simply forgot to adjust my clock, then asking for 2:15 I'd actually get back 02:15 -08:00.

Correct, but that absolute point in time is canonically labeled as "03:15 -07:00" in America/Los_Angeles. Using the "pre-transition offset" does not influence how we render the resulting absolute time point---it only determines how we produce that time point from the input YMDhms fields.

Algebraically, YMDhms + UTC_offset == time_point (for some definition of +). Then we can render that absolute time point in any zone we choose. So,

"2011-03-13 02:15:00" + "-08:00" => "2013-03-13 03:15:00 -07:00"
"2011-03-13 02:15:00" + "-07:00" => "2013-03-13 01:15:00 -08:00"

where the right-hand sides are the absolute time points rendered using America/Los_Angeles.

We could render those same time points using UTC instead:

"2011-03-13 02:15:00" + "-08:00" => "2013-03-13 10:15:00 +00:00"
"2011-03-13 02:15:00" + "-07:00" => "2013-03-13 09:15:00 +00:00"

The "pre" field is the time_point obtained using the pre-transition offset (-08:00 in the example), and similarly the "post" field is the time_point obtained using the post-transition offset (-07:00 in the example).

Check out the cctz talk at CppCon15 http://www.youtube.com/watch?v=2rnIHsqABfM where this stuff is discussed starting at about the 27:00 mark.

Bradley

from cctz.

Thanks for the explanation. Much clearer now. The key is that the pre/post describes how the input date+time is interpreted, not how it is rendered. I understood the resulting values, just not in the order they were originally described.

BTW - This sort of thing is common in other date/time APIs, but just described differently. The pre fields for both spring and fall both align with most of the common cases, so I suppose that it's good that they are obtained by the same field. All that's really different with cctz is that all three (pre,trans,post) are given at once.

For instance, Java 8 default its LocalDateTime.atZone method, to what you would consider pre in both cases. If you wanted your post values then for the fall-back transition, it has a different API in ZonedDateTime.withLaterOffsetAtOverlap, but it doesn't have one for the spring-forward transition.

I also work on Noda Time - a similar library for .NET (by @jskeet), and it's had various "resolvers" that give options to control these behaviors. It's default "lenient" resolver recently went through some changes in nodatime/nodatime#365 for the upcoming 2.0 release - this aligns it with Java 8's defaults, and your pre fields.

In terms of real-world use cases, the pre fields are almost always desirable in scheduling applications, such as running a task at the same time every day. If the time-to-run on a particular day is in the spring-forward gap, then it makes sense to run at the equivalent instant as if the clock wasn't adjusted. If it lands in a fall-back transition, then running in the first instance tends to still make more sense than waiting for the second.

The post field, choosing the later instance of the fall-back transition, tends to come up with businesses that are open late. For example, bars that (in some jurisdictions) can get an extra hour to sell drinks before closing.

I've thought these things considerably for many years, and I'm still scratching my head to think of a real-world use case for the post value during a spring-forward transition. Let me know if you encounter any. 😄

from cctz.

Watching the CppCon video now. Great stuff so far! I've given almost the same talk many times to .NET & JS audiences. Great to hear it from a C++ perspective!

And thanks for this library - I used to recommend Boost for C++ time zone work, but was floored when I learned it just hardcode mapped offset pairs to tzdb zones. So what else does that leave - ICU is what most are using I think, but that comes with a lot of overhead.

from cctz.

LOL, the graphs shown around 28:50 are almost identical to the ones I made for StackOverflow - just the axis is flipped. 😄

from cctz.

:-) Thanks for all the feedback @mj1856

from cctz.

This sort of thing is common in other date/time APIs, but just described differently. The pre fields for both spring and fall both align with most of the common cases, so I suppose that it's good that they are obtained by the same field. All that's really different with cctz is that all three (pre,trans,post) are given at once.

Yes. Note also that MakeTime() (as opposed to MakeTimeInfo()) returns just pre directly, so the common disambiguation rule is easy to use.

LOL, the graphs shown around 28:50 are almost identical to the ones I made for StackOverflow - just the axis is flipped.

We had them that way originally too, but then thought that having the civil time on the X axis and the skipped/repeated slices being vertical was a little more natural (at least to our way of thinking).

from cctz.