DateInput test is not passing for other time zones

except for a date-related one because the test doesn’t allow for my +10 timezone.

Expected Behavior

all tests should pass

no errors

Actual Behavior

Different time zones fail the dateinput test

URL, screen shot, or Codepen exhibiting the issue

Steps to Reproduce

Your Environment

• Grommet version:
• Browser Name and version:
• Operating System and version (desktop or mobile):

[DanielBaird]

I wish I had made this issue when I came across it the first time. From memory the problem is when the “correct” datetime is dinked together as a string with timezoneOffset, which is made like this:

    if (timezoneOffset < 10) timezoneOffset = `0${timezoneOffset}`;

In Australia my timezone is +10, which makes a negative timezoneOffset, but a negative number is less than 10 so it gets prepended with a 0 by that code. Then, subsequent dates assembled like this:

`${year}-${month}-20T${timezoneOffset}:00:00.000Z`,

…are crazy looking.

If I get a chance over the next few weekends I’ll try for a fix. Hopefully I can work out something that works in all timezones but doesn’t require adding Moment or date-fns or whatever to the deps.

Post a comment here if you start working on this so I can ping you and we don’t double up

[taysea]

I am wondering if we should update this test somehow – it seems part of the issue that has been happening is due to daylight savings timezone. According to this thread, there are functions we could create to see if a caller is in standard time or daylight savings, but according to the discussion under the reply it doesn’t necessarily seem like it’s fully reliable:

https://stackoverflow.com/a/11888430