There is confusion in the question and comments.
A time as we say informally is a point in time. It exists in a unique way. Time is something astrophysical, it has no time zone. That is why it is always right to treat points in time as UTC which is a universal time.
This site does this. And it’s the right one. In general websites have presentation problems because they don’t consider the spindle on the user’s machine. No big problem, the timing is right the presentation no, so this site chose not to try to guess the zone and uses UTC as presentation. I know a lot of people think it’s absurd, but this has its advantages, beyond the disadvantages.
In a more lay user application the ideal is to present the time within the zone. Presentation is something different from the time itself. Presentation is something visual, is eventual.
If the interest is the point in time does not matter much how the schedule entered or how it will present, only universal time matters. So if someone enters at 22:00 in GMT-0200 or 21:00 in GMT-0300 or 18:00 in GMT-0600, and then it makes no difference whether this is daylight saving or not, it’s time zone, everything will be 00:00UTC.
If the user’s machine is in the wrong zone is that machine’s problem. The most that can be done is for the system not to trust the operating system and to ask the user to inform what its spindle is. What is also unreliable, fool yourself even more. User makes confusion.
If something is set up wrong in the machine it is his problem. It is possible to create own alternatives to try to help.
Now, if you do not want a point in time then you need to save the time differently. If you want it visual time from the time the event occurred there record this time and not a point in time.
One way to do this is to record the time as local time same. You know that field is a visual representation of the time and not the time itself.
You can also continue recording UTC and have another field that tells you what use is used, so at the time of presenting you know how to calculate the presentation time.
Since this is not a point in time, it is not a quantification can even record a string with the schedule, it’s just a description.
If you have old hours in UTC and want to know what their time zone is without having it recorded, sorry, you have nothing to do, legacy error that will be loaded for the rest of your life. It’s like you use a integer and one day decide you wanted the decimal places of the recorded number.
I don’t think you’ll have a way to escape from informing in the database that a certain date was saved in daylight savings time, if you don’t report it, there’s no way of knowing, unless you create date range rules, as 'all dates saved in period 25/08/all up to 01/03/all' were saved in daylight time, and with this rule identify when to display the date if it was saved in that period, if yes discount the time, otherwise only display
– AnthraxisBR
A deal that makes no sense is when Voce quotes: "The problem is when I save the date in daylight saving time".. Let’s look at it: Imagine it’s 3:00 p.m. in UTC it would be 6:00 p.m., right? in daylight time it would be 4:00 p.m., and UTC 6:00 p.m., UTC time never changes.. what changes is the schedule that is converted.
– Thiago Loureiro
Jefferson there You need a conditional, when the date is within the daylight saving time (consulted date) Oce calculates +2, if not +3... the function in my answer does just that, imagine you seek a period of 01 year, and in the middle of that year the time has changed right? from June-2016 to June-2017.. so in the middle of the query, using function or the loop that you prefer to use you will have to validate and calculate correctly WITHIN THE DAYLIGHT TIME RANGE..
– Thiago Loureiro
But the point is, it’s both 7:00, so it’s all right. What you might want is to use the (local time* second hypothesis I mentioned in https://answall.com/questions/237072/hor%C3%a1rio-de-ver%C3%a3o-com-datas-antigas? noredirect=1#comment485421_237072. Normally this is a mistake, but if it’s what you want it gives too, only you can’t record more in UTC. You can record up to both, or some information that one calculates the other. It depends on your need. As I imagined from the beginning the need is not clear.
– Maniero
@bigown That’s just what I need, I need the date on localtime, but since the dates are recorded in UTC this causes some problems when you add summer time. So the solution would be to write out of UTC or else as a string? Or the Tolocaltime() when I use it it checks whether that period was daylight saving time or not to display the date in local time.
– Jeferson Almeida