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. GXDateTime and Convetring Date Time (Python)

GXDateTime and convetring Date Time (Python)

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 Lotusv , 5 May, 2022
Forums
Gurux.DLMS

When using the functions GXDateTime and GXDLMSClient.changeType
at some time, I began to have a discrepancy of 1 hour. When forward, when backward.
2022-03-27 03:00:00 in my zone (UTC+2) there was a change of time 1 hour ahead (to UTC+3).
Now in system:

Therefore TZ='Europe/Kiev' will be used.
Selected time is now: Thu May 5 18:14:26 EEST 2022.
Universal Time is now: Thu May 5 15:14:26 UTC 2022.

So...

Cdatetime: 2022-03-27 00:00:00
After:

GfromDate = GXDateTime(Cdatetime.replace(hour = 0, minute = 0, second = 0, microsecond = 0))
GtoDate = GXDateTime(datetime.datetime.now().replace(hour = 0, minute = 0, second = 0, microsecond = 0))
print(GfromDate, " ||| ", GtoDate, " ||| D Cdatetime: ", Cdatetime)

03/26/22 23:00:00 ||| 05/05/22 00:00:00 ||| D Cdatetime: 2022-03-27 00:00:00

After using GXDateTime I get -1 hour

In the same time:

print(Cdatetime1)
GfromDate1 = GXDateTime(Cdatetime1.replace(hour = 0, minute = 0, second = 0, microsecond = 0))
print(GfromDate1, " ||| D1 Cdatetime1: ", Cdatetime1)

2022-04-06 00:00:00
04/06/22 00:00:00 ||| D1 Cdatetime1: 2022-04-06 00:00:00

and...

Here I read the normal date-time from the counter, but I get an hour more.

GXDT = GXDLMSClient.changeType(Daydata[0][4], DataType.DATETIME)
DT = GXDT.toUnixTime(GXDT)
DayCurrent = datetime.datetime.fromtimestamp(time.mktime(DT))
print(type(GXDT), "|", type(DT), "|", type(DayCurrent), "|", type(time.mktime(DT)))
print(GXDT, "||", DT, "||", DayCurrent, time.mktime(DT))

<class 'gurux_dlms.GXDateTime.GXDateTime'> | <class 'time.struct_time'> | <class 'datetime.datetime'> | <class 'float'>
04/18/22 00:00:00 || time.struct_time(tm_year=2022, tm_mon=4, tm_mday=18, tm_hour=0, tm_min=0, tm_sec=0,
tm_wday=0, tm_yday=108, tm_isdst=0) || 2022-04-18 01:00:00 | 1650232800.0

I get time.struct_time with tm_isdst=0. I want to get tm_isdst=1. Maybe using timezone information solved the problem.
I trying
GXDT = GXDLMSClient.changeType(Daydata[0][4], DataType.DATETIME, useUtc=True)
but nothing changed.

At the same time:

UnixTime: 1650232800
GMT: Sun, 17 Apr 2022 22:00:00 GMT
Your time zone (UTC+3): 18.04.2022, 01:00:00

Looks like an error is happening in time.mktime(DT)

I can not understand what is the matter and where did I go wrong?

Lotusv

4 years 1 month ago

I shink that in

I shink that in GXDateTime.py
@classmethod
def fromUnixTime(cls, unixTime):
return GXDateTime(datetime.datetime(unixTime * 1000))

@classmethod
def fromHighResolutionTime(cls, unixTime):
return GXDateTime(datetime.datetime(unixTime))

looks like

@classmethod
def fromUnixTime(cls, unixTime):
return GXDateTime(datetime.datetime.fromtimestamp(unixTime * 1000))
and

@classmethod
def fromHighResolutionTime(cls, unixTime):
return GXDateTime(datetime.datetime.fromtimestamp(unixTime))

because there are mistakes (in fromUnixTime):
"integer argument expected, got float"
if I convert to int:
"signed integer is greater than maximum"
if I Unix timestamp devide by 1000 :
"function missing required argument 'month' (pos 2)"

i use fromHighResolutionTime for 10 digits unixtime

Lotusv

4 years 1 month ago

my second problem I decide:

my second problem I decide:

GXDT = GXDLMSClient.changeType(Daydata[0][4], DataType.DATETIME)
DT = GXDT.toUnixTime(GXDT)
DayCurrent = datetime.datetime(*DT[:6])

04/19/22 00:00:00 || time.struct_time(tm_year=2022, tm_mon=4, tm_mday=19, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=1, tm_yday=109, tm_isdst=0) || 2022-04-19 00:00:00

Lotusv

4 years 1 month ago

But why use GXDateTime in

But why use GXDateTime in Reader.readRowsByRange ?

when you can use standart datetime !!! That's right?

Profile picture for user Kurumi

Kurumi

4 years 1 month ago

Hi,

Hi,

It might be that your meter is not using DST. It might also be that your meter is not using a different deviation than you. There are several reasons why this might occur.
http://www.gurux.fi/Gurux.DLMS.Objects.GXDLMSClock

Can you add a hex trace here from Daydata[0][4] so I can check the values and tell why this is happening.

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