Is there a way to handle the UTC to Local time for time stamps that are in the future that accounts for Daylight Savings Time? I am capturing a UTC time for an event in the future, but want it to display in my current time, but this future time stamp is past the time change. It will show up an hour off until my local time is the same time offset as the future event.
I didn't see anything in the CML documentation for MEng.Time documentation.
You would need to probably create the actual time by setting the individual details, then get the stamp out. That should have the correct time accounting for such adjustments.
I vote to abolish DST
Here is the routine I am using, which takes a Unix Time that is some time in the future, adds the milliseconds to the end, then creates a CQC Time and CQC Card8 number. I am not sure what you mean about breaking out the individual pieces first. In the routine below, it will always set the Local time offset for today, even if the CQCTime is in the future.
Code:
Method UnixToCQCTime([In] String UnixTime,[Out] Card8 CardTime) Returns Time
Begin
Locals=
Card8 TmpCard;
String TmpStr;
Time CQCTime;
EndLocals;
TmpStr := UnixTime;
TmpStr.Append("0000000");
TmpCard := TmpStr.ToCard8();
CQCTime.SetFromStamp(TmpCard);
CQCTime.UTCToLocal();
CardTime := CQCTime.GetStamp();
Return CQCTime;
(03-10-2020, 04:22 AM)gReatAutomation Wrote: [ -> ]I vote to abolish DST
I'd back you on that one. It's really ridiculous in this day and age.
(03-10-2020, 05:23 AM)kblagron Wrote: [ -> ]Here is the routine I am using, which takes a Unix Time that is some time in the future, adds the milliseconds to the end, then creates a CQC Time and CQC Card8 number. I am not sure what you mean about breaking out the individual pieces first. In the routine below, it will always set the Local time offset for today, even if the CQCTime is in the future.
Code:
Method UnixToCQCTime([In] String UnixTime,[Out] Card8 CardTime) Returns Time
Begin
Locals=
Card8 TmpCard;
String TmpStr;
Time CQCTime;
EndLocals;
TmpStr := UnixTime;
TmpStr.Append("0000000");
TmpCard := TmpStr.ToCard8();
CQCTime.SetFromStamp(TmpCard);
CQCTime.UTCToLocal();
CardTime := CQCTime.GetStamp();
Return CQCTime;
Are you sure that time is seconds since 01/01/1970? What types of numbers are you ending up with?
So a date within the JSON shows 1552456800, and the UnixToCQCTime method posted above will change it to 15524568000000000. This date converts to 03/13/2020 at 6:00 am (UTC). If I run this before daylight savings time has occurred on my system and apply the conversion to get it to a local time (UTCtoLocal), it will subtract 6 hours. If I do this after daylight savings time it will subtract 5 hours.
I guess what would be optimal is if the UTCToLocal() command would know that the time is in Daylight Savings Time, and correct it accordingly.
I'm not doing any of that stuff myself. Windows is doing those calculations, I just wrap them. It's hard to imagine that Windows would get something that wrong. How are you testing this to make the system thing it is DST or not?
(03-13-2020, 01:16 PM)Dean Roddey Wrote: [ -> ]I'm not doing any of that stuff myself. Windows is doing those calculations, I just wrap them. It's hard to imagine that Windows would get something that wrong. How are you testing this to make the system thing it is DST or not?
I have two drivers - Google Calendar & RainMachine - both post dates in the future, of course the Google Calendar does it further out. If I have a date in DST time, I get the UTC time via a HTTP Get command, and then when I convert it to local time, it uses the current offset for today and applies it to that date.
I will ponder this a bit, and see if I can figure out a way to know that the date is either DST or normal time. The optimum solution would be for UTCToLocal() function to know, based on my location, what the proper local time would be for that date in the future.
I really do not miss having to do time calculations. When I was tackling time issues for a start up where I once worked, time was important because we were delivering over the air content, sending stuff over satellite, etc.
Decided to store anything time related in the data base in UTC represented by Epoch time (milliseconds). This was for everything. Database timestamps, schedules. Literally anything time related. For customer stuff, there was a column in that table that had the customer's UTC offset. Same for other things.
DST was a huge PITA because there are states that do not recognize it, as well as countries. Was another flag it the database.