I am trying to use a timezone aware datetimes. While I am aware of alternatives like anvil.tz.tzoffset(hours=3), I don’t want to use static offsets as I would like my application to be timezone aware.
I have tried using pytz, but the library failed to import.
ModuleNotFoundError: No module named '_thread'
at /lib/lib-python/3/threading.py, line 4
called from /site-packages/pytz/lazy.py, line 1
called from /site-packages/pytz/__init__.py, line 19
called from ServerModule1, line 13
called from /libanvil/anvil_downlink_worker/__init__.py, line 70
called from /libanvil/anvil_downlink_worker/__init__.py, line 176
I am assuming this failed to import due to the PyPy Sandbox.
I also tried using pendulum and arrow, alternative date libraries, but both of those failed to import due to not being installed.
As an aside, is there a list of packages available on the free plan? Although not explicit, the list of packages at Anvil Docs | List of Packages appears to only be correct for the paid plans.
What is the preferred approach to using timezones on the free plan?
That creates a time in the timezone of the browser. That page also talks about situations in which Anvil automatically sets the timezone of a datetime object.
Yes, I tried tzlocal(). My particular use case doesn’t benefit from tzlocal() as I need timezone info on a server-side REST call. I can’t pass a datetime to the call as it is being called from a IOT device.
Server side datetimes are automatically in UTC. Some graphical widgets will automatically convert those to the browser time zone when you send them to the client, and some don’t.
Maybe you can describe your use case in more detail?
Sure. I have a simple little anvil application that allows me to enter upcoming important dates. This works great and was really easy to build.
For the display side, I have a microcontroller driving a e-ink display. This microcontroller doesn’t have a RTC and doesn’t know the time. But it can be configured with its time zone.
So to save processing power on the microcontroller and to increase flexibility, I do the display and date formatting server side. To this end the server needs to know the timezone information for the client. This information is needed to be able to make determinations of wether a given date is in the past, is today or tomorrow.
Right now I am using hard coded timezone offsets, but I would like to be able to use a library like pytz, so I can just specify the timezone and have the library handle the daylight savings time and offset.
This would be accomplished by passing a tzinfo to date aware Python methods.
How this all works is the IOT device makes a REST call to the server with the text description of the timezone (US/Eastern). The server return back the next 10 events. Notating which ones are the present day, the next day and the number of seconds to midnight all according to the timezone that was passed in.
Well, as you noted in your original post, those sorts of server side packages are only available on the paid plans. So you’re pretty much reduced to working with anvil.tz related calls.
If you’re configuring the timezone of the client device, why not configure it with the offset you need for anvil.tz.tzoffset and send that offset to the server?
The offset in many places changes twice a year. So I don’t want to be required to update the offset each time a timezone goes on or off of daylight savings time.
Pytz is installed it, just doesn’t import. Not having timezone support seems like a pretty big oversight, so I just assumed that I was doing something wrong.
Also is there a list of packages available on the free plan?
As far as I know, none of the third-party packages are available on the free plan. Someone with more experience than me can chime in if that’s wrong.
It’s awkward to not be able to get the current datetime on the client device. You can, however, install any libraries you want on that device. You could install pytz on it, send back the UTC datetime from the server, and handle the timezone aware formatting on the client device.
Remember the client device is a battery powered microcontroller. It is silly to do extra processing on an energy constrained microcontroller due to deficiencies in the server.
I ended up monkey patching the load of the threading module, then mocking out the RLock class. This allowed me to load the pytz module without errors.