Deal with timezones #19
Conversation
Correction of typos
|
Thanks for your contribution. I'm traveling until early March, so I'll not
be able to look into the PR until then.
One useful function to the python code would be to make it into a package
(library) so please can in CV lude it in their project using pip. Do you
think you can look into it?
Thanks again.
…On Tue, Jan 14, 2025, 2:49 PM fdlamotte ***@***.***> wrote:
Hi Ivo,
This is the result of last week's experiments I've made :
- added a tz_helper.py with functions to get the timezone from system
and prepare structs for setting timezone
- made _TZ versions of get_world_cities, get_dst_for_world_cities,
get_dst_watch_state to update the timezone if it changed before writing the
registers
- I noticed a drift in time when doing sync => try to get the current
time as close as possible to sending it and add an offset
Since it was already in my file, the PR about sending all events instead
of enabled ones is included in this one ...
------------------------------
You can view, comment on, or merge this pull request online at:
#19
Commit Summary
- 8ff27c2
<8ff27c2>
Deal with timezones
File Changes
(2 files <https://github.com/izivkov/GShockTimeServer/pull/19/files>)
- *M* src/gshocktimeserver/gshock_api.py
<https://github.com/izivkov/GShockTimeServer/pull/19/files#diff-0ee52fcb62b08de505e256c9a2cbe42148dc2e35974c09a8e95118d43d56ae32>
(68)
- *A* src/gshocktimeserver/tz_helper.py
<https://github.com/izivkov/GShockTimeServer/pull/19/files#diff-5bb09068630bd894d9c37f8822b3fe641fe3515a56676023ffbb85ad361a3a2c>
(112)
Patch Links:
- https://github.com/izivkov/GShockTimeServer/pull/19.patch
- https://github.com/izivkov/GShockTimeServer/pull/19.diff
—
Reply to this email directly, view it on GitHub
<#19>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7M37SXCZVKZ54MLABVJ2T2KTJDDAVCNFSM6AAAAABVENYKDGVHI2DSMVQWIX3LMV43ASLTON2WKOZSG44DMNRTHA4DSMQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
You're welcome ;) This packaging issue is also something I'd like to see ... And I've started digging in the mechanisms to make a real library. Unfortunately I'm not a python dev (I've been using it to do some scripts because of all the available libs, but that is really the first time I'm writing python code across different files, so I'm learning ...) That is definitely something I have in mind, so when ready I'll propose something. I think at this moment it will be time to extrat the api from GShockTimeServer. I've had some issues when wanting to add arguments to my scripts, because the class dealing with arguments for the app is automatically loaded by the api (to deal with the logger config)
|
|
👍
…On Tue, Jan 14, 2025, 3:28 PM fdlamotte ***@***.***> wrote:
You're welcome ;)
This packaging issue is also something I'd like to see ... And I've
started digging in the mechanisms to make a real library.
Unfortunately I'm not a python dev (I've been using it to do some scripts
because of all the available libs, but that is really the first time I'm
writing python code across different files, so I'm learning ...)
That is definitely something I have in mind, so when ready I'll propose
something. I think at this moment it will be time to extrat the api from
GShockTimeServer. I've had some issues when wanting to add arguments to my
scripts, because the class dealing with arguments for the app is
automatically loaded by the api (to deal with the logger config)
Thanks for your contribution. I'm traveling until early March, so I'll not
be able to look into the PR until then. One useful function to the python
code would be to make it into a package (library) so please can in CV lude
it in their project using pip. Do you think you can look into it? Thanks
again.
… <#m_-1167244241340664819_>
On Tue, Jan 14, 2025, 2:49 PM fdlamotte *@*.*> wrote: Hi Ivo, This is the
result of last week's experiments I've made : - added a tz_helper.py with
functions to get the timezone from system and prepare structs for setting
timezone - made _TZ versions of get_world_cities, get_dst_for_world_cities,
get_dst_watch_state to update the timezone if it changed before writing the
registers - I noticed a drift in time when doing sync => try to get the
current time as close as possible to sending it and add an offset Since it
was already in my file, the PR about sending all events instead of enabled
ones is included in this one ... ------------------------------ You can
view, comment on, or merge this pull request online at: #19
<#19> Commit Summary -
8ff27c2
<8ff27c2>
<8ff27c2
<8ff27c2>>
Deal with timezones File Changes (2 files
https://github.com/izivkov/GShockTimeServer/pull/19/files
<https://github.com/izivkov/GShockTimeServer/pull/19/files>) - M
src/gshocktimeserver/gshock_api.py
https://github.com/izivkov/GShockTimeServer/pull/19/files#diff-0ee52fcb62b08de505e256c9a2cbe42148dc2e35974c09a8e95118d43d56ae32
<https://github.com/izivkov/GShockTimeServer/pull/19/files#diff-0ee52fcb62b08de505e256c9a2cbe42148dc2e35974c09a8e95118d43d56ae32>
(68) - A src/gshocktimeserver/tz_helper.py
https://github.com/izivkov/GShockTimeServer/pull/19/files#diff-5bb09068630bd894d9c37f8822b3fe641fe3515a56676023ffbb85ad361a3a2c
<https://github.com/izivkov/GShockTimeServer/pull/19/files#diff-5bb09068630bd894d9c37f8822b3fe641fe3515a56676023ffbb85ad361a3a2c>
(112) Patch Links: -
https://github.com/izivkov/GShockTimeServer/pull/19.patch
<https://github.com/izivkov/GShockTimeServer/pull/19.patch> -
https://github.com/izivkov/GShockTimeServer/pull/19.diff
<https://github.com/izivkov/GShockTimeServer/pull/19.diff> — Reply to this
email directly, view it on GitHub <#19
<#19>>, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA7M37SXCZVKZ54MLABVJ2T2KTJDDAVCNFSM6AAAAABVENYKDGVHI2DSMVQWIX3LMV43ASLTON2WKOZSG44DMNRTHA4DSMQ
<https://github.com/notifications/unsubscribe-auth/AA7M37SXCZVKZ54MLABVJ2T2KTJDDAVCNFSM6AAAAABVENYKDGVHI2DSMVQWIX3LMV43ASLTON2WKOZSG44DMNRTHA4DSMQ>
. You are receiving this because you are subscribed to this thread.Message
ID: @.*>
—
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7M37QWG22SEYEKJISJRBL2KTNTXAVCNFSM6AAAAABVENYKDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBZGQ4DENZSGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
btw, if you're interested, I've had some progress on my own scripts I've implemented some menus (using a dmenu clone, called bemenu, already used for the whole sxmo interface) and most of the functionality I needed are now implemented ... Bemenu can work with ncurses, so these are functionalities that could be backported to the timeserver, as well as the use of khal/vdirsyncer to easily get events from a caldav server ... The code is here, I've just put screenshots of some menus : https://git.sr.ht/~fdlamotte/sxmo_gshock I've read you're having issues with branding ... these things happen and I really like to show you my support ... They are owners of their brands, but I think you did them more good than bad. In my case, for instance, the only reason why I chose this watch over other products (and I found garmin watches to be very interesting too) is because you had made solid progress on reverse and were proposing the python api. I'm thinking about removing the gshock term from my app name, I thout about YWatch for Yellow Watch (because I have the yellow ga-b2100) but there is already a tracking app with this name ;) Regards Florent |
|
Ok, would that run on Linux as well, or only on SXMO? Do you enter your own
reminders or does it come from the calander?
About the branding, I would not worry too much about it in your case. It is
confusing for the users to see something like g-watch instead of G-Shock. I
opted not to change the names for that reason. Casio never bothered with me
for 4 years, until my app started showing in playstore search before thier
app. In your case, your app is not competing with theirs, so they will not
go after you.
Regards
…On Tue, Jan 14, 2025, 7:10 PM fdlamotte ***@***.***> wrote:
btw, if you're interested, I've had some progress on my own scripts
I've implemented some menus (using a dmenu clone, called bemenu, already
used for the whole sxmo interface) and most of the functionality I needed
are now implemented ...
Bemenu can work with ncurses, so these are functionalities that could be
backported to the timeserver, as well as the use of khal/vdirsyncer to
easily get events from a caldav server ...
The code is here, I've just put screenshots of some menus :
https://git.sr.ht/~fdlamotte/sxmo_gshock
I've read you're having issues with branding ... these things happen and I
really like to show you my support ... They are owners of their brands, but
I think you did them more good than bad. In my case, for instance, the only
reason why I chose this watch over other products (and I found garmin
watches to be very interesting too) is because you had made solid progress
on reverse and were proposing the python api.
I'm thinking about removing the gshock term from my app name, I thout
about YWatch for Yellow Watch (because I have the yellow ga-b2100) but
there is already a tracking app with this name ;)
Regards
Florent
—
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7M37UIFLU4E42D5OFMKJL2KUHT7AVCNFSM6AAAAABVENYKDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBZHEZTOMBWG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I think even sxmo_gshock could run on vanilla linux, most interactions with the system are done using shell commands, stored in sxmo_commands.json. The only commands that are not yet configurable are for getting notifications and launching the menu (sxmo_dmenu command is hardcoded in sxmo_dmenu.sh, and should not ;)). So I think configuring sxmo_gshock for running out of sxmo would just be a matter of giving the good commands in the json file (empty sxmo_vibrate, sxmobar, discard_calls, silent_toggle; and a state_read command that would return unlocked, so the menu would always be shown ;)) If the menu system is backported, the only dependency would be bemenu, but a simplistic fallback in python could be provided
Some reminders are sent headless
But there is also a menu for reminders, where you can configure all the reminder structure, and auto-fill it from events in the 30 next days here is the menu for reminders (this is the curses version, that shows on a terminal ;))
By selecting "make reminder from event" it opens a menu, populated from a khal command. The date and text are parsed and used to create the reminder (so there are only simple reminders)
The same can be done with alarms, but the list of events shown is for the next 24 hours
|
|
There is an issue in my proposal ... It might not be able to retreive the timezone (I've exprienced it after a system update, where some system path have changed) The problem is that if I ask Python for my timezone, it will tell me CET in winter and CEST in summer, while I want it to say Europe/Paris ... The only way I found to get the good result is to get realpath for /etc/localtime, it works both on sxmo and debian (sxmo is not based on systemd so the /etc/timezone file does not exist). My code assumed that /etc/localtime was a symlink to a file in /etc/zoneinfo ... while in debian (and now also with sxmo since yesterday), the file is in /usr/share/zoneinfo ... I'll find a more clever and robust way to get that ... if you have some idea ;) |
|
Yeah, this is one reason I did not implement timezones in the python
version. It runs on all kinds of computers, with no guarantee that they are
aware of their location, unlike the Android phones.
…On Wed, Jan 15, 2025, 2:09 PM fdlamotte ***@***.***> wrote:
There is an issue in my proposal ...
It might not be able to retreive the timezone (I've exprienced it after a
system update, where some system path have changed)
The problem is that if I ask Python for my timezone, it will tell me CET
in winter and CEST in summer, while I want it to say Europe/Paris ... The
only way I found to get the good result is to get realpath for
/etc/localtime, it works both on sxmo and debian (sxmo is not based on
systemd so the /etc/timezone file does not exist). My code assumed that
/etc/localtime was a symlink to a file in /etc/zoneinfo ... while in debian
(and now also with sxmo since yesterday), the file is in
/usr/share/zoneinfo ...
I'll find a more clever and robust way to get that ... if you have some
idea ;)
—
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7M37ROGC3JWK6BFBMUYID2KYNFFAVCNFSM6AAAAABVENYKDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJRHE2DOMZRGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
That is exactly what I thought when implementing this ;) What do you think is better ?
|
2 participants
Hi Ivo,
This is the result of last week's experiments I've made :
Since it was already in my file, the PR about sending all events instead of enabled ones is included in this one ...