tz: time zone support test

[urapadmin]

@arch-kiosk/test

This is about the test of time zone support in Kiosk 1.6.6 and up.
📖 First of all, here is the latest documentation on time zone support in Kiosk: [[https://wiki.arch-kiosk.brown.edu/urapdev/doku.php?id=development:kiosk_and_time]]. I suppose it makes some sense to read it now even though it is not a page turner.

🗒 And then we add testing tasks here and if something goes wrong, turn them into an individual tickets (so that this ticket here does not become a monster)

• tz test: single test of the synchronization cycle (does it work, basically?)

[luizaogs]

Synchronization is fine, also checked director's view and q&v.

[urapadmin]

• tz: check all the python now()s #2807 (comment)

[urapadmin]

Kiosk 1.6.6.1

to support time zone testing the file edit dialog has a test feature that should only appear on PVD:

The modified_utc field shows what is actually in the "modified" field in the database. (The other, regular modified date on the dialog shows the wrist watch time of that (if available, otherwise it should be the same as _utc) and time zone if there is any.

[urapadmin]

@arch-kiosk/test To support the time zone zone test there are now four queries in Q&V that allow you to see the actual database values of "modified" (the utc or legacy modified time stamp), "modified_ww" (wristwatch time, the one you usually see on the UI) and the time zone "modified_tz" plus a translation into the long time zone name.

That should help with testing. All queries are sorted by "modified" in descending order.

[urapadmin]

not as useful but there now: Time Zone Test: Images which lists ALL images by descending modified value. The only ways to identify an image is by its UID or by its context independent description

PS: Don't trip over the query "Time Zone Test: Image records". That was a mistake that I can't get rid of until 1.6.6.2. The right query is "Time Zone Test: Images"

[urapadmin]

Tests in two different time zones, one later and one earlier than UTC

I suggest Europe/Amsterdam (currently on daylight savings time UTC+1) and Mountain Time (US/Arizona) (which does not have DST and is on UST-7). And then we look at the results in Kiosk (Q&V or File Repository) in a time zone that is neither the one nor the other

So UTC-7 and
UTC+1

UTC-7 adds locus A in unit 1, UTC+1 adds locus B in unit 2 at more or less the same moment

• Q&V should show the modification time exactly as it was in the respective time zones
• in the tz test query for loci you should see for those two loci that they have a time zone and _ww and modified should make sense
• When exporting again to the two FileMakers the original wristwatch time should show in the record info for both added loci on both apps

UTC-7 modifies the description of unit 2/locus B, UTC+1 modifies the description of unit1/locus A at more or less the same moment

• Q&V should show the changed modification time exactly as it was in the respective time zones
• in the tz test query for loci you should see for those two loci that the time zones have switched and _ww and modified still make sense
• When exporting again to the two FileMakers the changed wristwatch time should show in the record info for both added loci on

Now let's work in the same unit and locus on different continents:

UTC-7 changes the description of locus B AGAIN, UTC+1 changes the record type of the same locus B to "architecture" (or whatever) at more or less the same moment

• synchronization should run smoothly
• Q&V should reflect both those changes properly

UTC-7 changes the description of locus B AGAIN a minute before UTC+1 as well changes the description of the same locus B

• synchronization should report a conflict and resolve it in favour of UTC+1, whose change was the most recent
• Q&V should show UTC+1's description
• the locus test query should show the correct _tz, _ww and modified values of UTC+1 for locus B

Now the other way around: UTC+1 changes the description of locus B AGAIN a minute before UTC-7 as well changes the description of the same locus B

• synchronization should report a conflict and resolve it in favour of UTC-7, whose change was the most recent
• Q&V should show UTC-7's description
• the locus test query should show the correct _tz, _ww and modified values of UTC-7 for locus B

[luizaogs]

Are you two doing this? Do you want me to help? It will clearly require coordination, which is why I ask.

[urapadmin]

I'll put my testing hat on and do it myself with two iPads. That's easiest.

[urapadmin]

a snap shot of one of the rare collisions that one never sees in praxis (or at least I have never heard of anybody noticing it):

WARNING: !Synchronization collision in table "locus", field "description", record "987a0e42-329b-45ef-8907-29fc448304f1":
INFO: | uid_unit || type || opening elevations || closing elevations || description || date_defined || date_closed || interpretation || colour || excavated_with || formation_process || elevation_opening_nw || elevation_opening_ne || elevation_opening_se || elevation_opening_sw || elevation_opening_ct || elevation_closing_nw || elevation_closing_ne || elevation_closing_se || elevation_closing_sw || elevation_closing_ct || datum_point_elevation || width || length || depth || volume || id || arch_domain || arch_context || alternate_id || uid || created || modified || modified_by || recorded_by || modified_tz || modified_ww || repl_deleted || repl_tag || repl_workstation_id |
| WINS: >e39c6338-4d2c-47b6-bad0-281146afcc5b| ac| None| None| Modifying Unit 2 locus B| changing the description again by lkh-7 This change should be moot| None| None| None| None| None| None| None| None| None| None| None| None| None| None| None| None| None| None| None| None| None| None| None| B| None| 987a0e42-329b-45ef-8907-29fc448304f1| 2024-10-30 17:07:07| 2024-10-30 17:08:05+00:00| LKH-7| LKH1| 71957968| 2024-10-30 10:08:05| False| 0| utc-7 |

Yes, they are hard to read. But with some formatting it gets a bit easier:

This tells you what column to look at: WARNING: !Synchronization collision in table "locus", field "description", record "987a0e42-329b-45ef-8907-29fc448304f1":

uid_unit	type	opening elevations	closing elevations	description	date_defined	date_closed	interpretation	colour	excavated_with	formation_process	elevation_opening_nw	elevation_opening_ne	elevation_opening_se	elevation_opening_sw	elevation_opening_ct	elevation_closing_nw	elevation_closing_ne	elevation_closing_se	elevation_closing_sw	elevation_closing_ct	datum_point_elevation	width	length	depth	volume	id	arch_domain	arch_context	alternate_id	uid	created	modified	modified_by	recorded_by	modified_tz	modified_ww	repl_deleted	repl_tag	repl_workstation_id
WINS> e39c6338-4d2c-47b6-bad0-281146afcc5b	ac	None	None	Modifying Unit 2 locus B, changing the description again by lkh-7 This change should make it.	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	B	None	987a0e42-329b-45ef-8907-29fc448304f1	2024-10-30 17:07:07	2024-10-30 17:08:21+00:00	LKH1	LKH1	34944030	2024-10-30 18:08:21	False	0	utc1
e39c6338-4d2c-47b6-bad0-281146afcc5b	ac	None	None	Modifying Unit 2 locus B, changing the description again by lkh-7 This change should be moot	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	None	B	None	987a0e42-329b-45ef-8907-29fc448304f1	2024-10-30 17:07:07	2024-10-30 17:08:05+00:00	LKH-7	LKH1	71957968	2024-10-30 10:08:05	False	0	utc-7

So, this tells us that the first record won in the synchronization collision and so the description of that record is synchronized in

[urapadmin]

is that kind of collision mentioned in the admin's manual? I think it should as it is more or less here that synchronization culminates.

[urapadmin]

more tests in two different time zones

Again:
Mountain Time UTC-7 and
Amsterdam UTC+1

UTC-7 delete locus A in unit 1 BEFORE UTC+1 changes locus A a minute later

• synch should run smoothly and locus A should not be deleted
• Q/V should show the changes of UTC+1 and the correct modified time stamps

UTC-7 changes locus A in unit 1 a minute AFTER UTC+1 deletes locus A in unit 1

• synch should run smoothly and locus A should not be deleted
• Q/V should show the changes of UTC-7 and the correct modified time stamps

---

• but note: synchronization: Deletion Collision can lead to fragmented records #2943

UTC-7 changes locus A in unit 1 a minute BEFORE UTC+1 deletes locus A in unit 1

• synchronizing both together should run return an information (details!) and locus A should remain. See kiosk sync: a record that got modified by one dock and deleted by another is never dropped #2945

[urapadmin]

image tests

Mountain Time UTC-7 and
Amsterdam UTC+1

UTC-7 adds image to locus A, UTC+1 adds image to locus B

• sync should sync them both
• The file repository should show them both with the correct time zones and time stamps

UTC-7 modifies (replaces) image in locus B, UTC+1 modifies image in locus A

• sync should sync both changes
• The file repository should show them both with the correct time zones and time stamps

UTC-7 modifies (replaces) image in locus A one minute AFTER UTC+1 also modifies image in locus A

• sync should run with a collision info
• The file repository should show the image in locus A to be that of UTC-7 and the correct time zones and time stamps

UTC-7 deletes image in locus A UTC+1 deletes image in locus B

• sync should run properly
• the files should both be gone

[urapadmin]

buap test (when rolled out)

• Test if buap and particularly the anc import feature still do what they should (@lbestock )