[grey-area]

All that tells you is the timezone the user was in (or if you're unlucky the timezone the server was in) when the data was recorded. So it's not usually very valuable information.

It doesn't tell you anything about the time zone this particular user would want to see it in today, which depends on quite a few factors including where they are and what the timestamp relates to (booking, event, log of past events etc).

[mro_name]

> So it's not usually very valuable information.

then you may be fine with that information loss. But is is one nevertheless.

[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.