I want to read the face value date time on the DatePicker (ie, what I can see with my eyes) but:
The date property gives a time aware one which his driving me insane.
The text property is unavailable in Anvil
I am comparing datetimes with data in a DB.
I don’t want any corrections for (blasted) timezones!
So how do I get a tz UNAWARE datetime on the server that AGREES with the face value datetime I can see on the (blasted) GUI?
I have tried DOZENS of approaches with pytz commands.
If the datetime picker says Wed, Jun 12, 2019 6:13 AM then, guess what, I want the datetime on the server to say that (as a tz unaware datetime).
Is that not unreasonable?
(Also, I’ve realized the datetimes displayed are wrong anyway. They have assumed the dates they were given are timeaware in the server timezone! So they don’t agree with the vs timeplot I’m showing! How ridiculous. I can’t see a property to make the picker timezone agnostic.
So, ALSO, how do I give the date picker a datetime from the server which will appear as sent?)
If you pass a timezone-unaware datetime between client and server, it will be made timezone-aware (in the timezone of the sending code) before transmission. We do this because an unaware timestamp is probably not what the user wants.
As you do want to send it over unaware, you have two options:
Format it to a string with strftime, send that, then strptime on the other end. This matches the model you want - you don’t want to communicate “the instant in time chosen by the user”; you want “the text displayed on the face of the time picker”.
Send the timestamp, then force it back to being naive again on the other end: Eg:
# On the client
anvil.server.call('foo', self.datepicker_1.datetime)
# On the server
@anvil.server.callable
def foo(dt):
dt = dt.replace(tzinfo=None)
# dt's hour/minute/etc are unchanged, but it's now
# naive again
I tried using that.
But my first problem was going the other way around.
I never quite got it working and had to just add/subtract subtract 10 hours. Not very professional.
It should have a mode where it works at face value.
The only reason for time zone aware is analyzing server logs. But most other applications are based on data that has NOTHING TO DO WITH THE SERVER! Booking hotels, plotting historical time data etc etc etc.
I really must say that a FORCED time aware component is one of the silliest things I’ve ever heard of in software development. Not to mention converting my time unaware datetime into aware without option! Just being honest.
For the record, here’s why I think I am correct that it is very wrong (probably even silly) to automatically (with no recourse to stopping it) adjust datetimes as they are swapped between server and client:
Consider I have a list of events that occurred in World War II.
Why would anyone want those datetimes timezone adjusted?
They are likely events that occurred at their local timezones, and are all different.
My case is similar.
It’s IoT data logged on IoT devices.
I don’t care where it originated most of the time.
And I certainly don’t want anyone assuming its timezone except for me, the programmer.
The only case in which it is useful to automatically convert datetimes between server and client is for . . server logs. And that is surely not the majority of datetime data. The majority is probably financial transaction datetimes and I can’t see why Anvil should be changing our financial transaction times when they hit the server (especially since their origin location is probably not the browser/upload location anyway).
Feel free to argue the opposite. Good luck!
BTW: What I want is a way to store time data in my Anvil DB datetimes in a face value, time-zone free way (and recover them to the browser unchanged).
No, they are events that occurred at a point in time that can be represented in different ways depending on your locale, language, alphabet and time zone.
If you ask an English when D-day started, they will say 5:30, if you ask a French they will say 6:30.
My Anvil apps often list documents or events with their creation time. The user is often interested on their freshness. Created 30 min ago is fresh, 3 hours ago not so much. Can you imagine the mess that would come if users in California and in New York got the same time of an arbitrary tone zone? The same document would be 30 min old for one and created in the future for the other.
The clean way to do this is to store the time in UTC, regardless of where the server is located (because data is often stored in several servers distributed in different tone zones), and adjust it according to the browser’s time zone. I don’t find it wrong or silly, I don’t see any problem with it.
Storing non time zone aware times instead can be very confusing and error prone. Looking at the time stamp of an iot event recorded at 6:30 in New York while sitting in front of a computer in California at 4:00, that sounds silly.
There are indeed legitimate uses for naive date/time representations (calendar applications are a common example). However, we’ve found that most of the time, when someone passes a datetime to/from the server, they want it to refer to the same instant on both sides. That’s why we have adopted timezone-awareness as the default.
As with any default, there will be some (usually advanced) users for whom it’s not what they want – and, on this occasion it sounds like you’re one of them! The important thing is that it’s possible for you to do whatever you want, even if you have to override the default behaviour to do it. I think we’ve achieved that – I’ve described a couple of ways above. As always, it’s a trade-off, but overall we’re happy where we’ve ended up, so you should architect your apps expecting it to stay that way.
In my WWII example, I would likely have no idea of the timezone they were relevant to. And by switching timezones automatically, I could no longer run a quiz question like ‘which battles were daytime ops’ because on the server they’ve been changed to non-local = non-sensical (in this case) times.
I’ll just have to learn how to correct for it as Meredydd (and you) suggest.
(And what if the guy on the browser entering the WWII data is moving thru timezones? I think it might mean I have to track him.)
That’s all fine Meredydd, but, let’s forget about datepickers for now.
What about the fact I now have data from an Anvil instigated SQL call in an Anvil DB.
Q. What is the best way to restore the ORIGINAL naive datetimes in the DB?
(Because Anvil has changed all my datetimes in the table)
Well, here I am a year later.
Still nearly in tears on datetimes that change between server and client.
Can you show me HOW you would swap a datetime (like the exact time of the start of World War 2 in an unknown timezone) from server to client and have it NOT change (and NOT convert it to a string)?
Hi Paul
I can’t understand you issue, this app seems to work fine IMHO.
Picks a datetime on the client, sends it to the server, without converting to string, without changing it.
On the AnvilServer (UK?) I make a remote SQL request to our MSSQLServer (US??) for temperature vs datetime plot data for produce truck journeys and store them in the AnvilServer Anvil DB (so I can do Machine Learning on the AnvilServer without making hundreds of MSSQLServer calls later)
On the AnvilServer I calculate ‘leg’ boundaries (ie start & stop datetimes) for different phases of each journey
On the CLIENT (AUSTRALIA) I make request for a particular journey data and PLOT it in PLOTLY (temperature vs time)
I get problems using the CLIENT datetime-pickers to select timeperiods to plot (ie wrong selection)
I MIGHT be getting problems plotting color-coded journey-legs using datetime boundaries calculated on the server
I get problems comparing sets of boundaries after a user changes them using another date-picker on the client.
All of this is caused by the inability of Anvil to allow me to have time-zone unaware datetimes since my data from a server in the US has nothing to do with the US! So, throughout my code sometimes need to correct for the timezone difference between Australia and the UK. I don’t think I’m getting a US timezone effect. I have TRIED to remove timezone info and failed 100 times.
What to you looks like the ‘right’ time on a datetime picker has secret timezone information in it. And I often can no longer keep track of which objects I calculated locally vs on the server.
It really is stupid because Anvil assumes that we want data relevant to the time-zone of the 3 computing devices involved when its about a journey that occurred at a FOURTH location UNRELATED to any of the computers, sometime in the past at an unspecified geo-location which in fact is changing during the journey because it’s a . . journey . . and in fact it’s a journey ACROSS time-zones!!
Remember, Anvil automatically converts timezone-unaware datetimes to timezone-aware datetimes when they are passed between client and server. I’ve tried to convert back to timezone-unaware but of course it changes the face-time value of the datetime from what it used to be UNLESS I actually correct it for the timezone difference by knowing where the browser is and where Anvil is.
Hi Paul,
I read your description, but I still don’t understand where is the problem.
If the time you are storing is the time of the request, then the server knows what time it is in UTC, so the timezone is not a factor here.
If the time comes from an Anvil client or an Anvil uplink, then the timestamp comes with a timezone and it is automatically converted to UTC when it arrives to the server, so the timezone is not a factor either.
If the time comes from another source, without timezone, then that is a problem to fix by adding the timezone awareness.
Time objects sent to the client are converted to the client timezone and everything looks perfect.
4, 5, 6. What problems are you getting?
You shouldn’t keep track. You know that the timestamps on the server are always in UTC and on the client on the local timezone.
Then I read the rest of your post and I don’t understand your scenario.
Can you describe an example scenario of what happens and what is your expectation?
Like @stefano.menci, I also read the description, but could not quite figure out the issue.
My understanding of this thread in general was that you wanted to send timestamps between the client and server, at face value (timezone unaware).
If I am understanding you correctly, you can achieve this by following either of suggestions above from Meredydd (e.g., .replace(tzinfo=None)).
Here is a clone to demonstrate sending and retrieving dates. The dates remain unchanged as they are passed back and fourth between the client and server:
Is this aspect of the issue solved?
Now, it seems as though you are also retrieving timestamps from some external server (not necessarily from a DatePicker on the client). Have you tried making those timestamps unaware prior to storing them in your Anvil DB? I would think that when those are returned to the client, wherever the client is located, that they would stay at face value, which is I think what you are looking to achieve.
I’m probably not understanding the issue exactly, so please correct me if I’m mistaken.