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

Strange results with Australia/Brisbane and Asia/Dubai #8

Closed
glasserc opened this Issue Dec 9, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@glasserc

glasserc commented Dec 9, 2015

At https://github.com/glasserc/weird-tzs I have pushed a test program that demonstrates a strange behavior that we saw in production. It takes the date 2015-11-23 midnight in Brisbane and converts it to UTC. On my machine, its output is:

$ cabal run
Preprocessing executable 'weird-tzs' for weird-tzs-0.1.0.0...
Local time:
2015-11-23 00:00:00
reading date is 2015-08-25 12:37:52 UTC

Compare with the output if you change Brisbane to Sydney:

$ ./dist/build/weird-tzs/weird-tzs
Local time:
2015-11-23 00:00:00
reading date is 2015-11-22 13:00:00 UTC

Certain timezones seem to be affected by this. Asia/Dubai is and Asia/Singapore is, but Asia/Baku isn't.

Interestingly, running the same code in the repl behaves correctly:

$ cabal repl Main.hs 
Warning: Ignoring 'Main.hs. The whole executable 'weird-tzs' will be built.
(Support for module and file targets has not been implemented yet.)
[...]
[1 of 1] Compiling Main             ( Main.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Local time:
2015-11-23 00:00:00
reading date is 2015-11-22 14:00:00 UTC
*Main> 

Any idea what's going on? This showed up after we switched from tzdata + timezone-series to tzdata + tz.

@klao

This comment has been minimized.

Show comment
Hide comment
@klao

klao Dec 9, 2015

Member

Wow, this is weird.

I'm on a short vacation right now, but I'll try to take a look at this as soon as possible!

Member

klao commented Dec 9, 2015

Wow, this is weird.

I'm on a short vacation right now, but I'll try to take a look at this as soon as possible!

@klao

This comment has been minimized.

Show comment
Hide comment
@klao

klao Dec 9, 2015

Member

OK, I just quickly checked for now if I can reproduce this issue. And, indeed I can. :)
So, I'll hopefully be able to debug this...

Member

klao commented Dec 9, 2015

OK, I just quickly checked for now if I can reproduce this issue. And, indeed I can. :)
So, I'll hopefully be able to debug this...

klao added a commit that referenced this issue Dec 10, 2015

@klao klao closed this in e6f58bb Dec 10, 2015

@klao

This comment has been minimized.

Show comment
Hide comment
@klao

klao Dec 10, 2015

Member

Wow, this was embarrassing. I'll fix the restrictive bounds on dependencies and will push it to hackage soon.

Thanks a lot for the bug report!

Member

klao commented Dec 10, 2015

Wow, this was embarrassing. I'll fix the restrictive bounds on dependencies and will push it to hackage soon.

Thanks a lot for the bug report!

@pjrt

This comment has been minimized.

Show comment
Hide comment
@pjrt

pjrt Dec 10, 2015

@klao Any idea why this worked in the repl? Your change looks really straight forward yet I can't see why it worked in the repl and not the program.

pjrt commented Dec 10, 2015

@klao Any idea why this worked in the repl? Your change looks really straight forward yet I can't see why it worked in the repl and not the program.

@klao

This comment has been minimized.

Show comment
Hide comment
@klao

klao Dec 10, 2015

Member

Sure. The thing is, it was accessing past the end of a vector. And what happens to be there depends on how the allocator works and what kind of things does the program allocates, when etc. And, the allocator in a compiled Haskell program works quite differently from the interpreter (mostly because of the optimizations, but the interpreter allocates some additional stuff too).

And so, it works deterministically (mostly?) in both cases, but the comparison in the localToPOSIX function swings to the favor of the last element of the vector (valid) in the interpreter, and the one after the last (invalid) when compiled, because the memory immediately after the vector gets different values in the two cases.

Member

klao commented Dec 10, 2015

Sure. The thing is, it was accessing past the end of a vector. And what happens to be there depends on how the allocator works and what kind of things does the program allocates, when etc. And, the allocator in a compiled Haskell program works quite differently from the interpreter (mostly because of the optimizations, but the interpreter allocates some additional stuff too).

And so, it works deterministically (mostly?) in both cases, but the comparison in the localToPOSIX function swings to the favor of the last element of the vector (valid) in the interpreter, and the one after the last (invalid) when compiled, because the memory immediately after the vector gets different values in the two cases.

@klao

This comment has been minimized.

Show comment
Hide comment
@klao

klao Dec 10, 2015

Member

OK, I've decided that it's time to "release" this this package, at least as an alpha. So, I uploaded it to Hackage as 0.1.0.0. It should be available soon. Woo!

Thanks again, guys!

Member

klao commented Dec 10, 2015

OK, I've decided that it's time to "release" this this package, at least as an alpha. So, I uploaded it to Hackage as 0.1.0.0. It should be available soon. Woo!

Thanks again, guys!

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