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

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.

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 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 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 [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 [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 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.