[Scarblac]

Well, garbage in garbage out, of course.

But in applications where it matters, you make sure you know the source timezone where the data enters your system.

[grey-area]

Which applications does it matter for?

[shpx]

This can matter when timezone definitions change, such as when a country decides to start/stop following daylight saving time.

If I schedule something for 1 pm 6 months from now, and a transition to/from DST is supposed to happen at some point during those 6 months, and then my country decides to not follow DST anymore or to follow DST year-round, once you update your timezone database and convert your UTC stored time to my timezone, it's going to either be 12 or 2 pm now. This is probably not what users want, unless they scheduled the event to happen a certain time interval after some other event that's not affected by timezones.

[grey-area]

Thanks, I was thinking more about an application that requires it day to day.

So a future event made before the time zone transition of a country? That's rare enough that I think a one-off transition plan would be fine.

Given the downsides of storing dates with time zones (comparison, confusion etc), it doesn't seem very attractive to me.

[Scarblac]

Data you store that you later want to analyse in a way that cares about the time of day.

E.g. when during the day is traffic at its worst, when is temperature highest, etc.