Skip to main content
Home
for DLMS smart meters
Open source solutions for DLMS smart metering

Main navigation

  • Home
  • Products
  • About us
  • Open Source
  • Community
  • Forum
  • Downloads
User account menu
  • Log in

Breadcrumb

  1. Home
  2. Forums
  3. Timezones When Scheduling Firmware Activation

Timezones when scheduling firmware activation

Forum Rules

Before commenting read Forum rules

Don't comment the topic if you have a new question.

You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.

By AndreasAtPowel , 1 October, 2019
Forums
Gurux.Net

We are trying to schedule a firmware activation in Star meters.
The system running our code currently runs in UTC+2 (Swedish summer time)
The meters runs in UTC+1 (Swedish normal time)
So we adjust the time to match the meters timezone like:
Ex.
var normalTime = firmwareInformation.ScheduleTime.Value.ToUniversalTime().AddSeconds(utcDiffSec);
var activateTime = new DateTimeOffset(normalTime.Year, normalTime.Month, normalTime.Day, normalTime.Hour, normalTime.Minute, normalTime.Second, normalTime.Millisecond, TimeSpan.FromSeconds(utcDiffSec));

var activationSchedule = new GXDLMSActionSchedule(scheduleLogicalName) { ExecutionTime = new[] { new GXDateTime( activateTime ) } };

utcDiffSec in this case is meters UTC offset in seconds (+3600).

When examining the GXDateTime object you can see that Value (that is a DateTimeOffset object) contains three DateTime properties:
- UtcDateTime which is the UTC time of what we entered, that is normalTime - utcDiffSec
- DateTime that contains the time we entered (normalTime)
- LocalDateTime which is a calculated value matching the systems timezone, DateTimeKind.Local

When this is sent to meter it seems that it is the LocalDateTime that is sent, and consequently meter schedules one hour to late in this example.

Shouldn't it be the DateTime object that should be sent? Or what are we doing wrong? As it is now we have to do a lot of manipulation to adjust for this, since there are no requirements in what timezone system should run, all we know is the timezone of the meter.

Profile picture for user Kurumi

Kurumi

6 years 8 months ago

Hi,

Hi,

The Execution time of Single Action Schedule is sent in two parts, Date and time. The problem here is that deviation or DST flag is not sent. This causes that execution time must use the same time zone and DST what meter is using and the system time zone is ignored.

You can just skip time zone info and set the time that you want to use. Don't try to change date time value to the different time zone.

BR,

Mikko

  • Create new account
  • Reset your password

Hire Us!

Latest Releases

  • Tue, 06/09/2026 - 11:16
    gurux.dlms.java 4.0.95
  • Tue, 06/09/2026 - 10:03
    Gurux.DLMS.Python 1.0.199
  • Mon, 06/08/2026 - 13:39
    gurux.dlms.cpp 9.0.2606.0801
  • Mon, 06/01/2026 - 10:15
    gurux.dlms.cpp 9.0.2606.0101
  • Thu, 05/28/2026 - 16:06
    gurux.dlms.java 4.0.94

New forum topics

  • Error reading L&G Meter
  • Pass a TCP Client to GXNet
  • Australian EDMI Mk10D (Essential Energy area)
  • Strange mix of data notificiation vs get response
  • DLMS Connection
More

Who's new

  • Tuanhgg
  • Adel
  • charnon
  • Paddles
  • Miguel Ángel
RSS feed
Privacy FAQ GXDN Issues Contact
Follow Gurux on Twitter Follow Gurux on Linkedin