History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: QB-3721
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Robin Shen
Reporter: Robert Saladra
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Variable with "Prompt as Date Input" uses timezone, resulting in possible invalid date returned

Created: 31/May/21 10:22 AM   Updated: 01/Jun/21 03:07 PM
Component/s: None
Affects Version/s: 10.0.21
Fix Version/s: 11.0.3

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown

 Description  « Hide
I've used variable my_date with Prompt as Date Input setting, provided todays date (2021-05-31). Then I've tried to get that date in different format, using vars.get().asDate() and uitl.formatDate(), which gave me previous day instead of current. Minimal working example code below. It's clearly connected with user/instance timezone but I'd like to avoid hardcoding "add 1 day" wherever we use date variables.

my_date = vars.get("my_date")
logger.info("To string: " + my_date.toString())
// To string: 2021-05-31 +0200

logger.info("Date with underscores: " + util.formatDate(my_date.asDate(), "yyyy_MM_dd"))
// Date with underscores: 2021_05_30

logger.info("Full datetime object: " + util.formatDate(my_date.asDate(), "yyyy-MM-dd, HH:mm:SS Z"))
// Full datetime object: 2021-05-30, 22:00:00 +0000

 All   Comments   Work Log   Change History      Sort Order:
Robin Shen [31/May/21 01:23 PM]
It seems that your browser timezone is not the same as QB server timezone. When option "detect timezone" is enabled in QB system setting, input date will be in timezone of your local time, and when call various date formatting methods, it will be formatted using server timezone. You may turn that option off to make sure server date displays the same as your local time.

Robert Saladra [31/May/21 02:16 PM]
With this option turned off, all timestamps (build start time, logs etc.) will be displayed in server timezone, right? We support dev teams in different geolocations (from India +5:30, via Europe +1:00/+2:00, to West US -8:00), so they'll need to convert server timezone (GMT, if I recall correctly) to their local timezone in all these fields.

Is there a chance to make this one prompt timezone-agnostic? Prompt as DateTime input still should be aware of timezone.

Robin Shen [31/May/21 11:13 PM]
That will cause more problems. For instance, you intended to schedule a build at 05/31 00:00 your time, but it will actually run at 05/30 00:00 at server time which is different from yours.

Robert Saladra [01/Jun/21 10:29 AM]
Scenario You've provided should use datetime field, as scheduler requires exact time and should be timezone-aware. On QB cron schedulers already run on server timezone anyway, e.g. we have scheduler '0 30 3 * * ?' and builds start on 3:30 server time, which is GMT. Users are aware that cron schedulers have to be in local timezone and it's fully acceptable.

Issue I've reported is related to Date field. To add some context for provided example, let's assume we'd like to run a "build" that restores application DEV environment from a backup zipfile for user-specified day. Backups are named with underscores and kept in subdirectories for each year and month, e.g. backups/DEV/2021/05/2021_05_31.zip. To get that zipfile path and name from date-type QB variable, we'll have to use several regex/replace functions, where this should be possible with util.formatDate and single format: "yyyy/MM/yyyy_MM_dd". With current implementation and this approach we'll get file for previous day, and on the first day of a month, we'll even end up in subdirectory for previous month.

Robin Shen [01/Jun/21 11:16 AM]
Although it is a date field, if you call asDate() it will be converted to exact timestamp. If you do not want to use exact timestamp, just use it as a string. For instance getting the value via vars.getValue("var1") and removing trailing timezone.

Robert Saladra [01/Jun/21 01:25 PM]
And that's my point, java supports storing both datetime and date only (with and without timezones) and I see no reason to convert date fields to datetime on 00:00:00 server time. IMO both VariableWrapper and util.formatDate should support "date" as "date", not "datetime".
Working on strings requires regex/replace function to reformat output, while we might be using existing functions.

Robin Shen [01/Jun/21 02:21 PM]
Thanks for the info. I did not realized there is LocalDate since Java8. Will add extra method to convert variable value to LocalDate and extra method in util to format local date. Existing methods will not be changed for backwards compatibility.

Robin Shen [01/Jun/21 03:07 PM]
VariabeWrapper.asLocalDate() and util.formatLocalDate is added respectively in 11.0.3: