Rocket U2 | UniVerse & UniData

Hi Barry,

Some thoughts on how I've worked with some customers to do this.

To start off with SYSTEM(99)  in UniData returns the system time in the number of seconds since midnight in Coordinated Universal Time (UTC), January 1, 1970, this was implemented in UniData 8.1.

I then wrote  some UniBasic routines to be used in OCONV / ICONV (I don't know if you were aware you can write your own conversion codes in UniBasic to do this) which converted and displayed the stored UTC as required. This allowed me to use it programs like LTIME=OCONV(UTC.TIME,"UTCLC") where UTCLC would display the UTC time in local time. UTCLC is a cataloged program with a predefined agrument list (check the manuals if you haven't used this before).  Getting the correct timezone is the interesting part and displaying the converted UTC in which ever local zone is the interesting part and can become complicated, espically on Windows. All the customers I've worked with wanted one time zone per account, so this made it easier just to store a timezone code for that account and use that for converting.

I wrote versions that used some .NET code to it as well as UniBasic to do this.

These days I would probally look to get some free python code to do this simply and use this in UniData as well, to save myself some time.

Using SYSTEM(99) is the useful starting point though.

Seems to me the simplest solution is to store the time in Unidata in UTC and keep a control record per account of the offset.  Create your own OCONV routes to apply the time offset to dates and times, and you're there.  This would work as long as each account is on a different timezone.  If each user of the account could be connecting from a different timezone, I'd still store everything in UTC but keep a timezone offset on each transaction.  You said you're using web connections, so why not use a little Javascript to get the user's local time offset and send that along in the packet?

If anyone is interested I already have be spoke oconv iconv conversions written for these. I'll attach to the thread if anyone is interested. 

Seems to me the simplest solution is to store the time in Unidata in UTC and keep a control record per account of the offset.  Create your own OCONV routes to apply the time offset to dates and times, and you're there.  This would work as long as each account is on a different timezone.  If each user of the account could be connecting from a different timezone, I'd still store everything in UTC but keep a timezone offset on each transaction.  You said you're using web connections, so why not use a little Javascript to get the user's local time offset and send that along in the packet?

Hi Jonathan,

Yes, please, share your skills about it. 

It's always interesring ! 

------------------------------
Manu Fernandes

Original Message:
Sent: 09-28-2024 10:53
From: Jonathan Smith
Subject: Date and time in Unidata

If anyone is interested I already have be spoke oconv iconv conversions written for these. I'll attach to the thread if anyone is interested. 

------------------------------
Jonathan Smith
UniData ATS
Rocket Support

Original Message:
Sent: 09-28-2024 08:12
From: Kevin King
Subject: Date and time in Unidata

Seems to me the simplest solution is to store the time in Unidata in UTC and keep a control record per account of the offset.  Create your own OCONV routes to apply the time offset to dates and times, and you're there.  This would work as long as each account is on a different timezone.  If each user of the account could be connecting from a different timezone, I'd still store everything in UTC but keep a timezone offset on each transaction.  You said you're using web connections, so why not use a little Javascript to get the user's local time offset and send that along in the packet?

------------------------------
Kevin King
President
Precision Solutions, Inc.
Longmont CO US

Original Message:
Sent: 07-18-2023 06:18
From: Barry Green
Subject: Date and time in Unidata

Hi guys,

We have a situation where we want to have multiple Unidata accounts on a single Windows server but the accounts may related to customer sites in different time zones.

The front end will be a browser based web application.

If we use DATE() and TIME() that will pick up the date and time from the server which may not match the date/time relating to the location of the customer's site.

We have thought about

1. Calling an API to get the site "actual" time but that must rely on both an internet connection and the API always being available.
2. Maintaining a "time offset" setting but that's difficult with daylight saving as that can kick in on different dates each year and sometimes isn't required at all.
3. User the date/time from the users local PC but what if the user is travelling or simply has their date/time set incorrectly.

Has anyone come up with a good solution to this?

Many thanks

Barry Green
CBS Software
M: 0414 380192 T:08 82601256
www.cbssoftware.com.au<http: www.cbssoftware.com.au/="">
www.cbssoftware.com.au/terminal-operating-system<http: www.cbssoftware.com.au/terminal-operating-system="">
www.cbssoftware.com.au/depot-management-software<http: www.cbssoftware.com.au/depot-management-software="">

[CBS_Logo]</http:></http:></http:>

This is something I did based on customer questions around using UTC and timezones within UniData. It uses a python function, which utilizes the tzdata module for python (so if you do not already have the tzdata module installed, you will need to install it).

Python Functions

Timezones.py

UniBasic Programs

PYTHON.TIMEZONES (UniBasic Function calling the Timezones.py function)

PTZ (UniBasic Program for ICONV / OCONV)

TEST.PTZ.CALL (Test harness to for PTZ ICONV/OCONV and use in a file)

Create a test file called TZTEST with two dictionaries items,

:AE DICT TZTEST TSTAMP ZONE.TIME

< 1 > Top of "TSTAMP" in "DICT TZTEST", 6 lines, 20 characters.

001: D

002: 1

003:

004: UTC Stamp

005: 15R

006: S

Bottom.

*--:

< 2 > Top of "ZONE.TIME" in "DICT TZTEST", 6 lines, 27 characters.

001: D

002: 1

003: UPTZ

004: Time In Zone

005: 35L

006: S

Bottom.

TEST.PYTHON.TIMEZONES (Test harness I used when developing the idea for a customer)

You need to create a file called PY.TZONES for this to work (expand @ID to be 45T in the dictionary)

I hope you find it useful.

Hi Jonathan,

Yes, please, share your skills about it. 

It's always interesring ! 

If anyone is interested I already have be spoke oconv iconv conversions written for these. I'll attach to the thread if anyone is interested. 

Seems to me the simplest solution is to store the time in Unidata in UTC and keep a control record per account of the offset.  Create your own OCONV routes to apply the time offset to dates and times, and you're there.  This would work as long as each account is on a different timezone.  If each user of the account could be connecting from a different timezone, I'd still store everything in UTC but keep a timezone offset on each transaction.  You said you're using web connections, so why not use a little Javascript to get the user's local time offset and send that along in the packet?

Jonathan,

Were there supposed to be attachments to this post?  I cannot find any.

This is something I did based on customer questions around using UTC and timezones within UniData. It uses a python function, which utilizes the tzdata module for python (so if you do not already have the tzdata module installed, you will need to install it).

Python Functions

Timezones.py

UniBasic Programs

PYTHON.TIMEZONES (UniBasic Function calling the Timezones.py function)

PTZ (UniBasic Program for ICONV / OCONV)

TEST.PTZ.CALL (Test harness to for PTZ ICONV/OCONV and use in a file)

Create a test file called TZTEST with two dictionaries items,

:AE DICT TZTEST TSTAMP ZONE.TIME

< 1 > Top of "TSTAMP" in "DICT TZTEST", 6 lines, 20 characters.

001: D

002: 1

003:

004: UTC Stamp

005: 15R

006: S

Bottom.

*--:

< 2 > Top of "ZONE.TIME" in "DICT TZTEST", 6 lines, 27 characters.

001: D

002: 1

003: UPTZ

004: Time In Zone

005: 35L

006: S

Bottom.

TEST.PYTHON.TIMEZONES (Test harness I used when developing the idea for a customer)

You need to create a file called PY.TZONES for this to work (expand @ID to be 45T in the dictionary)

I hope you find it useful.

Hi Jonathan,

Yes, please, share your skills about it. 

It's always interesring ! 

If anyone is interested I already have be spoke oconv iconv conversions written for these. I'll attach to the thread if anyone is interested. 

Seems to me the simplest solution is to store the time in Unidata in UTC and keep a control record per account of the offset.  Create your own OCONV routes to apply the time offset to dates and times, and you're there.  This would work as long as each account is on a different timezone.  If each user of the account could be connecting from a different timezone, I'd still store everything in UTC but keep a timezone offset on each transaction.  You said you're using web connections, so why not use a little Javascript to get the user's local time offset and send that along in the packet?

This is something I did based on customer questions around using UTC and timezones within UniData. It uses a python function, which utilizes the tzdata module for python (so if you do not already have the tzdata module installed, you will need to install it).

Python Functions

Timezones.py

UniBasic Programs

PYTHON.TIMEZONES (UniBasic Function calling the Timezones.py function)

PTZ (UniBasic Program for ICONV / OCONV)

TEST.PTZ.CALL (Test harness to for PTZ ICONV/OCONV and use in a file)

Create a test file called TZTEST with two dictionaries items,

:AE DICT TZTEST TSTAMP ZONE.TIME

< 1 > Top of "TSTAMP" in "DICT TZTEST", 6 lines, 20 characters.

001: D

002: 1

003:

004: UTC Stamp

005: 15R

006: S

Bottom.

*--:

< 2 > Top of "ZONE.TIME" in "DICT TZTEST", 6 lines, 27 characters.

001: D

002: 1

003: UPTZ

004: Time In Zone

005: 35L

006: S

Bottom.

TEST.PYTHON.TIMEZONES (Test harness I used when developing the idea for a customer)

You need to create a file called PY.TZONES for this to work (expand @ID to be 45T in the dictionary)

I hope you find it useful.

Hi Jonathan,

Yes, please, share your skills about it. 

It's always interesring ! 

If anyone is interested I already have be spoke oconv iconv conversions written for these. I'll attach to the thread if anyone is interested. 

Seems to me the simplest solution is to store the time in Unidata in UTC and keep a control record per account of the offset.  Create your own OCONV routes to apply the time offset to dates and times, and you're there.  This would work as long as each account is on a different timezone.  If each user of the account could be connecting from a different timezone, I'd still store everything in UTC but keep a timezone offset on each transaction.  You said you're using web connections, so why not use a little Javascript to get the user's local time offset and send that along in the packet?