Default Timezone for Custom plugin date parameter

NN

Hi,

I am trying to add a date parameter to my custom python recipe.
The parameter in json is similar to one shared below.
i get the value selected by the user using get_recipe_config()

The problem is that the date gets adjusted for the timezone of the interface user.
As i can have users from multiple timezones is there any way that i can force UTC timezone on the parameter?
so that any date selected by the user will not get further adjusted by dataiku.

  {
    "name": "testdate",
    "label": "TEST DATE",
    "type": "DATE",
    "description": "Please select a date",
    "defaultValue":null,
    "mandatory": false,
    "visibilityCondition" : "model.datefilter"
  }

Thanks..

AndrewM

Hi NN,

By default, DSS stores all dates internally as UTC. When a date is entered in the "date picker", DSS assumes that the date is in the timezone of the server, and then converts the date to UTC before storing it. For example, this results in "01.01.2020" (assumed to be in UTC+1) being converted to "2019-12-31T23:00:00.000Z".

We have an open feature request with our product team to provide the option of storing dates entered via the date picker as strings; this would ensure that the literal date entered by the user is preserved in the backend.

In terms of a fix right now, there are 2 options:

1. String plugin parameter field instead of date

The solution here would be to use a "STRING" plugin parameter instead of a "DATE" parameter. This would unfortunately not allow users to use a "date picker", but it would simplify the code of the plugin (as you wouldn't have to shift the timezones). To ensure the users had entered a valid date, you could use an assertion similar to:

try:
datetime.strptime(self.start_date, '%Y-%m-%d')
except ValueError as e:
    raise ValueError("\"Start Date\" must be valid dates in YYYY-MM-DD format.") from e

2. Python code

The idea here would be to (1) detect the server timezone, (2) shift the datetime from UTC back to the server timezone, and (3) format the date to "DD.MM.YYYY". The following example implements something something along these lines (I've tested it in python 3.6):

from datetime import datetime
import pytz

# Note: "start_date" is the date as extracted from the plugin config dictionary
start_date = pytz.utc.localize(datetime.strptime(start_date, "%Y-%m-%dT%H:%M:%S.%fZ")).astimezone()

# Format start and end dates to string with "DD-MM-YYYY" format
self.start_date = start_date.strftime("%d-%m-%Y")

These are just samples and will likely require some additional development to get working with your plugin/use case.

Thank you
Andrew M

NN

ThankYou Andrew... I shall go ahead with the textbox option for now.

yashpuranik

Hi @AndrewM
,

Curious if this has been addressed in the releases since this post. We are also facing a similar issue and would like to avoid Python if we can.

Thanks,

Yash

yashpuranik

@AndrewM
: Is "When a date is entered in the "date picker", DSS assumes that the date is in the timezone of the server, and then converts the date to UTC before storing it" this still accurate? Just ran some tests and it looks like the DSS is assumes the date is in the timezone of the user (as communicated by the web browser) and not in the timezone of the server? If it is indeed the user, a script like you suggest above becomes mighty difficult to implement

AndrewM

Hi Yash,

This has not been added into the product in more recent versions.

Regarding my previous response, it was indeed incorrect. It's the users timezone that affects this. DSS will still store dates in UTC so the offset is based on the users browser timezone to UTC.

NN

@yashpuranik

One thing i felt is that If you are attempting to use this parameter in a plugin then a Textbox might be better to use- because if you wish to drive your date ranges from a scenario or project variables then defining those in a DATE-TYPE parameter might not work but it works easily in a TEXT-TYPE parameter.