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

Not sure if it's working properly or I am noob #67

Open
erikkubica opened this issue Feb 13, 2023 · 3 comments
Open

Not sure if it's working properly or I am noob #67

erikkubica opened this issue Feb 13, 2023 · 3 comments

Comments

@erikkubica
Copy link

Hey,

I am trying to do some test for a calendar and I have noticed some weird things.

I have just checked what time it is now in Tokyo it said it's "Feb 14 03:15" so I have mocked Etc/GMT+9 and initialized the date object with "2023-02-14 03:15:00". To make sure, I have initialized it with the same date in browser to check if it initializes with my current timezone or not, it was correct, so the Tokyo time should be accurate.

I have tried to convert the timezone-mock date object with moment and Intl, but all of them return wrongly converted timezone.

So I have something easier. My local timezone is CET (GMT+1) so I have mocked that. Initialized the date with my local time string and run a conversion to Europe/Bratislava (yes, form +1 to +1) and result was +2 (from 19:15 -> 21:15) because 1+1 is 2 right? Wrong.

I have started digging and tried to change "const date = new Date("2023-02-14 03:15:00");" to "const date = new timezoneMock._Date("2023-02-14 03:15:00");" to access the original date object. The test result is correct.

So basically, something is not right with the mocked Date object, because while date-time conversion works with the native Date, it does not work properly with the mocked Date.

So basically I am unable to test if my code works properly if I cannot get a functioning Date object in a certain timezone.

 test("convertDateIntoTimeZone | Tokyo => Bratislava | Convert date into timezone", () => {
        timezoneMock.register("Etc/GMT+9");
        // Mon Feb 14 2023 19:15:00 GMT+0900
        const date = new Date("2023-02-14 03:15:00");

        // Bratislava is GMT+1
        // Output should be: Mon Feb 13 2023 19:15:00 GMT+0100
        // Double-checked with bing and google and other online tools
        const dateAsGMT1 = new Intl.DateTimeFormat("sv-SE", {
            day: "2-digit",
            month: "2-digit",
            year: "numeric",
            hour: "2-digit",
            minute: "2-digit",
            timeZone: "Europe/Bratislava", // GMT+1 / CET
            timeZoneName: "short",
        }).format(date);

        // Fails: Output is "2023-02-14 13:15 CET"
        expect(dateAsGMT1).toEqual("2023-02-13 19:15 CET");
        // Expected: "2023-02-13 19:15 CET"
        // Received: "2023-02-14 13:15 CET"

        timezoneMock.unregister();
    });
@Jimbly
Copy link
Owner

Jimbly commented Feb 13, 2023

Not sure this only issue or not, but Tokyo should use Etc/GMT-9 timezone, see the note in the Readme, the Etc/GMT timezones are basically the opposite of what you'd expect. Since your output is off 18 hours from what you expect, that sounds likely to be the issue =)

@erikkubica
Copy link
Author

@Jimbly thank you that slipped my eyes after a long day. Just out of curiosity, why does it work in the opposite way? Are you trying to punish humanity?

@Jimbly
Copy link
Owner

Jimbly commented Feb 14, 2023

Heheh, not my decision, I also think it's terrible! We just pull the timezone names from the OS, and that's how the Etc timezones are defined I guess -_-. If you pass Etc/GMT+1 to Intl.DateTimeFormat in Node, you'll see it comes back as a GMT-1 date string too. Discussion about it here.

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