Skip to content

Make tests pass in 2020 #8688

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

Merged
merged 1 commit into from
Jan 24, 2019
Merged

Conversation

bmwiedemann
Copy link
Contributor

using only 2038 to keep 32-bit UNIX systems happy.

Background:
As part of my work on reproducible builds for openSUSE, I check that software still gives identical build results in the future.
The usual offset is +15 years, because that is how long I expect some software will be used in some places.

using only 2038 to keep 32-bit UNIX systems happy.
@eksperimental
Copy link
Contributor

This is great. PRs like this help us improve Elixir a lot. For instance, I just found a bug in the File module (Elixir doesn't know how to deal with dates that go after 03:14:07 UTC on 19 January 2038)
More info: https://en.wikipedia.org/wiki/Year_2038_problem

I will create an Issue

@josevalim
Copy link
Member

@eksperimental since we delegate to Erlang exclusively, that's really a conversation we need to have with the Erlang team. So can you please have this discussion there since our hands are tied on the matter? For now, we should document the behaviour though (in case it isn't).

@josevalim josevalim merged commit ae67b56 into elixir-lang:master Jan 24, 2019
@josevalim
Copy link
Member

❤️ 💚 💙 💛 💜

@bmwiedemann bmwiedemann deleted the ftbfs2020 branch January 24, 2019 13:50
@eksperimental
Copy link
Contributor

what's the best way to proceed? mailing list, issue tracker, or anything else..

@josevalim
Copy link
Member

@eksperimental for Erlang? I am not sure. Mailing list or a report on bugs.erlang.org.

@OvermindDL1
Copy link
Contributor

@eksperimental It would be nice to have a link to the erlang-side of the bug report here. :-)

@eksperimental
Copy link
Contributor

Thank you for the suggestion. I will share it here once published.

by the way, I would like to know if what happens in a 32bit-OS happens in a 64bit one.

Can anybody run this code?

iex(33)> File.touch "sample", {{2040, 1, 1}, {0, 0, 0}}
:ok
iex(34)> File.stat "sample", time: :posix     
{:ok,
 %File.Stat{
   access: :read_write, 
   atime: 1548350917,
   ctime: 1548350917,
   gid: 1000,
   inode: 2823216,
   links: 1,
   major_device: 46,
   minor_device: 0,
   mode: 33204,
   mtime: -2085978496,
   size: 0,
   type: :regular,
   uid: 1000
 }}

@josevalim
Copy link
Member

josevalim commented Jan 24, 2019

@eksperimental oh so it works today for 64 bit without issues. So if it only fails on 32-bit OSes, then I don't even think there is anything Erlang/OTP can do, we just need to make sure it fails accordingly (i.e. with {:error, :something}).

@eksperimental
Copy link
Contributor

eksperimental commented Jan 24, 2019

Erlang in the typespecs says the year can be from 1970 to 10000 or something like that with more 0s. but it depends on the OS. That's what I wanted to check.

@OvermindDL1
Copy link
Contributor

'stat' results used to be 32-bit timestamps on 32-bits, and 64-bits on 64-bits, however there is a field on the extended stat call that has expanded timestamp range, if OTP is not using that one then it should be.

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

Successfully merging this pull request may close these issues.

4 participants