Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timezones #4

Open
dbrgn opened this issue Sep 1, 2016 · 1 comment
Open

Timezones #4

dbrgn opened this issue Sep 1, 2016 · 1 comment

Comments

@dbrgn
Copy link
Contributor

dbrgn commented Sep 1, 2016

Gnucash exported the transactions using UTC time, while the Gnucash software is set to UTC+2.

Therefore transactions that occured on "2016/08/02" were exported as "2016/08/01 22:00" and interpreted as "2016/08/01".

I used this hack in gnucash.py to adjust:

import calendar

# ...

    def parse_time(time):
        dt = datetime.strptime(time, "%Y%m%d%H%M%S")                                                
        timestamp = calendar.timegm(dt.timetuple()) + 7200                                                               
        return datetime.utcfromtimestamp(timestamp)         

Maybe this could be made configurable using a CLI switch?

@MatzeB
Copy link
Owner

MatzeB commented Dec 22, 2017

I cannot reproduce this behavior with gnucash 2.6.18 in MacOS: i.e. when I add a transaction on 1/2/2013 (US locale) in gnucash, I see "20130102105900" in the database irrespective of my timezone settings. Similarily strptime used without a timezone modifier here should give us what they call a "naive object" in the documentation that should just print the same way it was parsed I think.

Maybe they changed the behavior in newer gnucash versions? (or does the mac version diregard the timezones?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants