[busterarm]

I'm sorry, but if you have an application dealing with time and you want to even think of defining a behavior independent of time zone, you should still be storing values in UTC.

Your example may work fine on a server that you control, but let's say your use case is a phone alarm program. You can't guarantee that your application will know when it's 7:30AM in the local time, but you can guarantee what the time is in UTC and not need network or the device's help to do it.

So now the time format you store depends on the architecture of your platform? What if you have to send this data between platforms now? Am I going to have to convert back and forth for each message? No thanks. I'll just store everything as UTC and stay sane.

[msandin]

Please make the distinction that _instants in time_ should be stored in the UTC but time specifications for scheduling purposes (10:30, mondays 14:50, 2017-05-17T13:40) are not instants in time, they are specification of time to be interpreted in a specific time zone and should be stored as such.

In a very real example there was once a product which let you schedule events by specifying a start date and a recurrence interval, say "daily". The software converted the start time to UTC in the zone of the schedule creator and stored that. But the conversion was done at the creation time which means it was done with a particular offset (say -5 hours) and when the relationship between the creators time zone and UTC changed as a result of DST changes the schedule ended up one hour of from what the creator intended. And the information about which timezone the thing had originally been scheduled in was lost and could not be retrieved.

[busterarm]

What was this like...1990?

This is 2017. Are you not putting all of your transactions in an ordered table in a database with creation timestamps? That information should not be lost and should be easy to figure out, in UTC. Figuring out the conversion of some other time/date is a solved problem.

There should never be a question of when some work happened if you're following sane practices.

I do huge ETL projects that live or die on the accuracy of our timing data. Give me date(time)s in UTC and I'm happy. Anything else? Pain.

[msandin]

Of course we knew who did what and when, that was not the problem and I never said it was. But the start date+time they entered for recurring series was converted to UTC on the client before it was sent to the server. So when it was decided that what they really wanted wasn't to run it "every 24 hours after the start date+time" but to run it on the exact time they entered every day, starting on the day they entered, the information about the exact time they had entered was gone.", all we had was that time converted to UTC. This meant we could not deduce the original time zone in which it was entered and thus could not deduce which DST schedule it should follow to keep it running at the same time every day.

[msandin]

The answer to the question "when did some work happen" is an instant and I specifically said that instants should be stored in UTC. I'm talking about storing recurrent schedules, i.e. information about when an (potentially infinite) series of future events should take place. And that information is not a series of instants and can't be stored as UTC timestamps because it's potentially infinite, subject to future reconfiguration, subject to future timezone offset changes, and must be preserved in a format that allows it to be viewed and edited (Thursdays odd weeks at 10:00 is not easy to glean from a series of pre-calculated numbers).