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.

Barry,

This is possibly overkill, but I did a series of blog posts on dealing with Date and Time in Python.

1 of 3: Dealing With Internal and Display Format Data in Your MV Database with Python

2 of 3: Dealing with the Python Time Module From Rocket MV Basic

3 of 3: Calling Python Time Module From MV User Defined User Exit

My simple example does not deal with time zones, but it does show an example of creating a User Defined User Exit, so you can decide to go down the path of just BASIC or BASIC and Python

Thanks Jonathan and Mike for your responses, given me something to look into.

Regards,

Barry

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. 

Hi Jonathan,

Yes, please, share your skills about it. 

It's always interesring ! 

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).

(See attachment progs.zip  further down in the thread it didn't upload first time)

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.

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

Jonathan,

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

Not a solution but a comment here. Staying with ICONV and OCONV for conversions is very nice. I think I'll try that some day in Universe.  For now, I use perl for epoch conversion because it was already installed and I'm just living off the land to get things done. For my needs its is a matter of UTC to LOCAL. I made a TCL program that takes various input formats and flags including UTC and LOCAL. I often execute the program from basic and I use the basic data command to feed the input. Its slow but my workaround is to run about 8 phantoms at same time.  I have not tried this on windows.

>CONVERT.EPOCH -D
 SH.CMD: PERL -e 'use Time::Local;print timelocal(40,17,9,30,8,2024)'
 SH.RETMSG: 1727702260 FCT: 1 VCT: 1
 SH.RET...: 0
>

CONVERT.EPOCH -D  1727702260
 SH.CMD: PERL -e "use POSIX; print strftime('%m-%d-%Y %T',localtime(1727702260))"
 SH.RETMSG: 09-30-2024 09:17:40 FCT: 1 VCT: 1
 SH.RET...: 0
09-30-2024 09:17:40 1727702260 LOCAL
>

CONVERT.EPOCH -D  1727702260  UTC
 SH.CMD: PERL -e "use POSIX; print strftime('%m-%d-%Y %T',gmtime(1727702260))"
 SH.RETMSG: 09-30-2024 13:17:40 FCT: 1 VCT: 1
 SH.RET...: 0
>

Perl Epoch Converter Routines

Mike B

------------------------------
Mike Bojaczko
PROGRAMMER ANALYST
US
------------------------------

Added progs.zip

Added progs.zip ... it didn't upload last time