Fix test dates for gigasecond

[Biraru]

This pull request updates the gigasecond exercise tests to use dates that are supported by Lua’s os.time. Previously, test 3 used the date 1959-07-19, which caused os.time to return nil and made the any_date parameter in gigasecond.anniversary nil. The test has now been updated to use 2009-01-19, which allows the function to correctly calculate the gigasecond anniversary and ensures the test passes as intended.

[github-actions]

This PR touches files which potentially affect the outcome of the tests of an exercise. This will cause all students' solutions to affected exercises to be re-tested.

If this PR does not affect the result of the test (or, for example, adds an edge case that is not worth rerunning all tests for), please add the following to the merge-commit message which will stops student's tests from re-running. Please copy-paste to avoid typos.

[no important files changed]

For more information, refer to the documentation. If you are unsure whether to add the message or not, please ping @exercism/maintainers-admin in a comment. Thank you!

[keiravillekode]

Which operating system version are you using? Which Lua version?

If we change the test, I think the adjustment should be by a multiple of 4 years, leaving the day and month unchanged:

e.g. input 1999, expected output 2031

[ryanplusplus]

Our example handles this properly so I'm also curious what's different about your setup.

[Biraru]

I'm using windows 11 and my Lua version is 5.1.5

[glennj]

That's a very old Lua version (https://www.lua.org/versions.html). Can you upgrade?

[ryanplusplus]

I tested this on macOS and Linux with version 5.1.5 and it worked. I don't have a Windows machine available to test, though.

I also perused the docs and there's no mention of os.time returning nil under any conditions.

[ryanplusplus]

Hey @Biraru, were you able to resolve this on your side or did you learn more about what's happening on your machine?

[Biraru]

I tested this on the latest Lua release, but the issue persists — os.time still returns nil. From what I can tell, this seems to be a Windows-specific limitation related to how time_t is handled.

[glennj]

Confirmed.

Running Lua 5.4 (from https://sourceforce.net/projects/luabinaries) in a Windows 11 VM.

PS C:\lua> ./lua54
Lua 5.4.2  Copyright (C) 1994-2020 Lua.org, PUC-Rio
> os.time
function: 0000000065ba1550
> os.time()
1756386947
> os.time({year=1970, month=1, day=1})
57600
> os.time({year=1970, month=1, day=1, hour=0, minute=0, second=0})
14400
> os.time({year=1969, month=12, day=31, hour=20, minute=0, second=0})
0
> os.time({year=1969, month=12, day=31, hour=19, minute=0, second=0})
stdin:1: time result cannot be represented in this installation
stack traceback:
        [C]: in function 'os.time'
        stdin:1: in main chunk
        [C]: in ?

While natively on my mac, time can be represented as a negative number

$ lua
Lua 5.4.8  Copyright (C) 1994-2025 Lua.org, PUC-Rio
> os.time({year=1969, month=12, day=31, hour=19, minute=0, second=0})
0
> os.time({year=1969, month=12, day=31, hour=18, minute=0, second=0})
-3600

[Biraru]

This issue can be resolved by setting the year to a value above os.time’s minimum.

[keiravillekode]

Please adjust the years by a multiple of 4 years, leaving the day and month unchanged. e.g.

    local actual = gigasecond.anniversary(os.time({ year = 1959, month = 7, day = 19 }))
    local expectedDate = os.date('%x', os.time({ year = 1991, month = 3, day = 27 }))

becomes

    local actual = gigasecond.anniversary(os.time({ year = 1999, month = 7, day = 19 }))
    local expectedDate = os.date('%x', os.time({ year = 2031, month = 3, day = 27 }))

[Biraru]

Okay

[Biraru]

Done