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

dateToInt -> intToDate does not roundtrip depending on time zone #1159

Open
darrenldl opened this issue Aug 8, 2022 · 3 comments
Open

dateToInt -> intToDate does not roundtrip depending on time zone #1159

darrenldl opened this issue Aug 8, 2022 · 3 comments
Assignees

Comments

@darrenldl
Copy link

Hello,

Context

I am the main developer of Timedesc - a modern alternative to calendar essentially,
and I was poking around at packages which depend on calendar out of curiosity to see if it causes issue in other packages (there have been known issues in ISO8601.ml etc).

(Interesting language! I like the language design quite a lot.)

Problem

For time zones outside of UTC, conversion from date time to timestamp and back yields a different date time.

Europe/London

$ TZ=Europe/London linx
 _     _ __   _ _  __  ___
/ |   | |  \ | | |/ / / ._\
| |   | | , \| |   /  \  \
| |___| | |\ \ | |\ \ _\  \
|_____|_|_| \__|_| \_|____/
Welcome to Links version 0.9.7 (Burghmuirhead)
links> var t1 = parseDate("2022-05-20 15:00:00+0");
t1 = 2022-05-20 16:00:00.000000+1 : DateTime
links> var t2 = dateToInt(t1);
t2 = 1653055200 : Int
links> var t3 = intToDate(t2);
t3 = 2022-05-20 15:00:00.000000+1 : DateTime
links> var t4 = dateToInt(t3);
t4 = 1653051600 : Int

Australia/Sydney

$ TZ=Australia/Sydney linx
 _     _ __   _ _  __  ___
/ |   | |  \ | | |/ / / ._\
| |   | | , \| |   /  \  \
| |___| | |\ \ | |\ \ _\  \
|_____|_|_| \__|_| \_|____/
Welcome to Links version 0.9.7 (Burghmuirhead)
links> var t1 = parseDate("2022-05-20 15:00:00+0");
t1 = 2022-05-21 01:00:00.000000+10 : DateTime
links> var t2 = dateToInt(t1);
t2 = 1653022800 : Int
links> var t3 = intToDate(t2);
t3 = 2022-05-20 15:00:00.000000+10 : DateTime
links> var t4 = dateToInt(t3);
t4 = 1652986800 : Int

UTC (this is fine)

$ TZ=UTC linx
 _     _ __   _ _  __  ___
/ |   | |  \ | | |/ / / ._\
| |   | | , \| |   /  \  \
| |___| | |\ \ | |\ \ _\  \
|_____|_|_| \__|_| \_|____/
Welcome to Links version 0.9.7 (Burghmuirhead)
links> var t1 = parseDate("2022-05-20 15:00:00+0");
t1 = 2022-05-20 15:00:00.000000+0 : DateTime
links> var t2 = dateToInt(t1);
t2 = 1653058800 : Int
links> var t3 = intToDate(t2);
t3 = 2022-05-20 15:00:00.000000+0 : DateTime
links> var t4 = dateToInt(t3);
t4 = 1653058800 : Int

I will say I don't know if I'm using links correctly, or how relevant this might be to links, or how the interaction with DB works etc.

@dhil
Copy link
Member

dhil commented Aug 8, 2022

Thanks! This looks like an issue for @SimonJF -- I'll let you have a look first.

@jamescheney
Copy link
Contributor

jamescheney commented Aug 8, 2022

I believe @SimonJF is away for a bit. It's totally plausible to me that we might not be doing the right thing here, especially since this may have been tested in a time/place where GMT/UTC would have been the default. Probably we should also be providing a variant of intToDate that takes an explicit timezone.

@SimonJF
Copy link
Member

SimonJF commented Aug 8, 2022

Thanks, will take a look when I’m back! I think @jamescheney is likely right in that we are probably relying on an underlying UK time assumption for intToDate. Wonder what happens on the client, too.

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

No branches or pull requests

4 participants