Thanks for the response.
Contrary to your statement above, my observations show that the designer does not appear to use the machines local timezone at all, but instead shows all timestamps in UTC. That is why its easy to get confused when looking at the System>CurrentDateTime and System>Timezone tags in designer as the date and time are shown in UTC time, and are not shown using the server's configured Timezone.
Reference: Get gateway Time through scritping - #13 by PGriffith
Yes, I understand that all ignition date objects (java.util.Date) are really just milliseconds since unix epoch. What I am trying to understand is why the designer context (tag browser and script console) defaults to applying UTC timezone when the gateway context defaults to applying the server's timezone. I'd expect it would make more sense to apply the server timezone for display of dates in the designer.
When it comes to scripting and date math this difference in timezone context is more significant than just formatting display of a date (milliseconds since unix epoch) as a string.
As an example, here is a script that finds and prints the start and end of the day that contains the date/time provided as a parameter. The function defined as a gateway script but changes behavior based on whether it is called from script console or a gateway event script: shared.date.printDayStartEnd(paramDate=None)
def printDayStartEnd(paramDate=None):
# CAUTION: this script returns different date values dependant on context
# - Designer context: assumes UTC (e.g. script console)
# - Gateway Context: assumes the OS timezone (e.g. gateway events)
# use date parameter if provided, if not assume now
myDate = paramDate if (paramDate is not None) else system.date.now()
# determine start and end dates (date-time), days may be 23-25 hours dependant on DST
myYear = system.date.getYear(myDate)
myMonth = system.date.getMonth(myDate)
myDayOfMonth = system.date.getDayOfMonth(myDate)
startDate = system.date.getDate(myYear, myMonth, myDayOfMonth)
endDate = system.date.addDays(startDate, 1)
print 'Start: {} End: {} Hours: {}'.format(startDate, endDate, system.date.hoursBetween(startDate, endDate))
Function calls:
shared.date.printDayStartEnd(system.date.getDate(2022, 2, 13)) # DST Start
shared.date.printDayStartEnd(system.date.getDate(2022, 10, 6)) # DST End
shared.date.printDayStartEnd()
Results when function calls are run from designer context (script console):
>>>
Start: Sun Mar 13 00:00:00 UTC 2022 End: Mon Mar 14 00:00:00 UTC 2022 Hours: 24
Start: Sun Nov 06 00:00:00 UTC 2022 End: Mon Nov 07 00:00:00 UTC 2022 Hours: 24
Start: Tue Oct 04 00:00:00 UTC 2022 End: Wed Oct 05 00:00:00 UTC 2022 Hours: 24
>>>
Results when function calls are run from gateway context (gateway timer script), output to wrapper.log:
Start: Sun Mar 13 00:00:00 CST 2022 End: Mon Mar 14 00:00:00 CDT 2022 Hours: 23
Start: Sun Nov 06 00:00:00 CDT 2022 End: Mon Nov 07 00:00:00 CST 2022 Hours: 25
Start: Tue Oct 04 00:00:00 CDT 2022 End: Wed Oct 05 00:00:00 CDT 2022 Hours: 24
Note the difference in the hours for each day, as UTC interpretation of dates does not use any DST adjustment. In this case I want the date math to include DST adjustments resulting in 23-25 hour days.
So, I understand the difference in behavior, but I'm not clear on the "why", whether that difference is intentional on the part of the ignition developers and whether there might be good rationale for keeping that difference... other than UTC representation of dates provides uniqueness that DST aware representations do not.
If there is not known intentional rationale for the difference, I'd make the following suggestions to ignition developers:
- Have the designer assume the same timezone context as the gateway context by default. For display of date values and scripted date math.
- For scripting, provide means to set the timezone context that applies to date object creation, date math (add/subtract) and date formatting.
- If you plan to keep UTC representation of dates in designer, show the timezone text 'UTC' as part of the formatted date representation for date values in the tag browser to help alleviate potential confusion.