# Installing pytz library **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [August 2, 2024, 3:56pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123 "2024-08-02T15:56:45Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [August 2, 2024, 3:56pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/1 "2024-08-02T15:56:45Z")
Good afternoon, I'm starting to play with different timezone and mssql database, looking here and there I see that in phyton is used the ```python pytz library ``` Should be possible to install it in Ignition? ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [August 2, 2024, 4:01pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/2 "2024-08-02T16:01:27Z")
Describe what you're actually trying to do in more detail. Installing Python libraries is ~never the answer. You should be using the Java standard library, which has comprehensive timezone information already available to you, but without knowing what you're actually trying to do, any advice will be uselessly vague. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 2, 2024, 4:01pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/3 "2024-08-02T16:01:37Z")
Don't use jython libraries where java has native support. Use `java.util.Date`, `java.util.Calendar`, or classes from [java.time](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/package-summary.html) and its sub-packages. ---
**Author:** ![Felipe\_CRM](https://avatars.discourse-cdn.com/v4/letter/f/dfb087/32.png) [@Felipe\_CRM](https://forum.inductiveautomation.com/u/Felipe_CRM)\ **Post date:** [August 2, 2024, 4:02pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/4 "2024-08-02T16:02:36Z")
Just for completeness' sake, [the github repo](https://github.com/stub42/pytz) for pytz shows it's C-based so it wouldn't work with Jython anyway. ---
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [August 2, 2024, 4:34pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/5 "2024-08-02T16:34:51Z")
Thank you all for the answers, you're right I try to explain what I need to do. I'm reading with kepware some PLC status in China (but in any case in future I will need to do the same in USA and other countries). I manage this status to chart the specific production lines (0 machine out of work, 1 running), so I write I script that every minute updates a mssql table in the way I need to have to visualize this data (for example I have the columns `StartDate` and `EndDate`. I'm in Italy so in this script when I write `system.date.now()` I have my timezone and in the table I write the "wrong" time, this is why I need to know the "difference" between my hour and the PLC hour to modify the columns `StartDate` and `EndDate` accordly. Thank you guys ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 2, 2024, 4:39pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/6 "2024-08-02T16:39:23Z")
The fundamental mistake here is using a database that isn't recording timestamps as UTC, or at least storing the origin time zone with the value. In MS SQL Server, use `datetime2` columns instead of `datetime` columns. In PostgreSQL, use `timestamptz` columns instead of `timestamp` columns. In MariaDB (or MySQL), use `timestamp(3)` columns instead of `datetime` columns. Do **not** write your own code to massage timestamps for perceived timezone issues. ---
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [August 2, 2024, 4:53pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/7 "2024-08-02T16:53:58Z")
Is not my choise to use a MS SQL Server, is IT that takes this decisions so unfortunately I need to adapt. I could use a datetime2 column if this avoid the problem, so you suggest to change the column type and insert directly my timezone datetime? And later when I will read the data what should I do to manage it accordly with the timezone? ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [August 2, 2024, 5:05pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/8 "2024-08-02T17:05:42Z")
> [@Aiasa21](#): > > and insert directly my timezone datetime? No, when the value is stored in the database, it should have the timezone included where the data originated. Then when you pull it, it would be converted into the corresponding time for your timezone (or the timezone of the client to be more correct). ---
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [August 2, 2024, 5:05pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/9 "2024-08-02T17:05:52Z")
> [@pturmel](#): > > at least storing the origin time zone with the value If I use this approce, how can I retrieve the origin time zone? Should I set it statically? ---
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [August 2, 2024, 5:06pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/10 "2024-08-02T17:06:53Z")
Ok, I'm missing this point, how can I know the origin timezone? ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [August 2, 2024, 5:19pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/11 "2024-08-02T17:19:52Z")
How are you collecting the data? The gateway that is connected to these PLC's in China should in theory have the correct timezone. So you would get it from there. The how depends on how you are collecting the data. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 2, 2024, 5:30pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/12 "2024-08-02T17:30:43Z")
If your are inserting Ignition ordinary datetime **objects** \[1\], via Ignition, into SQL Server, the proper information will be included. (The datetime2 column will receive the correct value, using the Ignition gateway's time zone.) When querying such data later, the timestamp+tz information in the `datetime2` column will be merged back into the pure UTC format used by `java.util.Date` internally, and then presented in user timezones as needed in Ignition. In other words, it Just Works™. * * * 1. This means `java.util.Date` objects delivered to inserts or updates using **value** parameters in Named Queries or `?` substitutions in scripted "Prep" queries. ---
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [August 2, 2024, 5:41pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/13 "2024-08-02T17:41:28Z")
Thanks for the explanation, of course I need to study the datetime2 and `java.util.Date` because until now I've always used `system.date` for me needs. I try to make an example about this because probabily I don't understand completely what you mean. I read data with Igniton (the gateway is in Italy), then I save the data into the DB that is in Italy too. So for example now in Shangai is 13:35, but if I insert into the DB the datetime value will be the gateway hour, so in this case 19:36. If I run the client from the Italy I will have no conversion or am I wrong? And in this case I will see "wrong" charts. Thank you for your patience. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 2, 2024, 5:43pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/14 "2024-08-02T17:43:58Z")
All of the `system.date.*` functions supply `java.util.Date` instances. And the corresponding expression functions. And all of the timestamps that show up in the tag system or anywhere else that used `QualifiedValue` objects. That is what Ignition uses **everywhere**. > [@Aiasa21](#): > > So for example now in Shangai is 13:35, but if I insert into the DB the datetime value will be the gateway hour, so in this case 19:36. As long as the gateway's clock and timezone are correct, the `datetime2` column will receive that timestamp **with** the gateway timezone. > [@Aiasa21](#): > > If I run the client from the Italy I will have no conversion or am I wrong? A client running in Italy will see the original Shanghai timestamp converted to the Italian timezone. Inside Ignition, the `java.util.Date` object will be carrying the UTC millisecond value **everywhere**. (Strictly speaking, the client will use the **project** timezone setting, which defaults to the timezone wherever the client happens to be.) ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [August 2, 2024, 5:48pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/15 "2024-08-02T17:48:48Z")
The difference is that `datetime2` also stores the time zone. So if you're storing the data at the gateway, it will store it with the gateway time and timezone (GMT+2 or GMT+1 depending on the time of year). Then depending on where you view it and configuration of the client, it will show that timestamp of the data in the local timezone. (Phil can correct me if I'm wrong) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 2, 2024, 5:50pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/16 "2024-08-02T17:50:57Z")
Another option is to run all of your gateways and databases set to UTC. Then you can use a regular (naïve) `datetime` column in your tables. Ignition, which handles everything with the UTC-based `java.util.Date`, will write UTC to the database, and read UTC from the database, and will handle all other time zone conversions (both directions) for you. ---
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [August 2, 2024, 6:01pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/17 "2024-08-02T18:01:00Z")
You must forgive me but the solution still eludes me. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/5/1582d7c0022e8612c245f624f7f7065734f922e4.png) From what I understand If I'm run the client (so I'm Italy) the datetime will be `02/08/2024 19:49` or not? Why the system should give me the Shangai conversion? I mean, I read the status from Italy, I write to Italy and I read the database from Italy.. I don't understand what's the moment where the Shangai datetime is managed. In the same why If a chinese run the client from Shangai in this case the timezone will be converted correctly right? And the point is that if I run from Italy, I need to see the actual datetime of Shangai, not the italian datetime. Sorry again, but this is a little bit tricky for me ---
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [August 2, 2024, 6:12pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/18 "2024-08-02T18:12:39Z")
This should be perfect but my problem is that I need to see always the Shangai datetime wherever the client is run in the world. For example if I run from Italy, from USA or wherever the "actual" datetime should be the actual Shangai time. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 2, 2024, 6:14pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/19 "2024-08-02T18:14:06Z")
> [@Aiasa21](#): > > I need to see always the Shangai datetime wherever the client is run in the world. Then set the **project** timezone to Shanghai. Whenever you have to deal with time zones, handle the **data** always in UTC, or with attached time zone, so there's never any ambiguity. Keep the **presentation** of time information, and the **entry** of time information, separate from the **transmission** of time information. ---
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [August 2, 2024, 6:20pm UTC](https://forum.inductiveautomation.com/t/installing-pytz-library/94123/20 "2024-08-02T18:20:27Z")
Actually I need to manage multiple timezone, Shangai, Atlanta, Italy and others in the same project. [Next page](https://forum.inductiveautomation.com/t/installing-pytz-library/94123.md?page=2)