Disclaimer: This is important change for anyone creating CUSTOM DATASETS or using Dropbox heavily. Otherwise, this will be seamless for customers utilizing just BrightGauge Default Datasets.
Today we released a major enhancement to how we handle date/times in BrightGauge. We particularly focused on how we can account for Daylight Savings Time changes more gracefully for our customers. This was a two pronged approach.
New Date Field Type
First, we added a new field type, the "Date" field type. This type of field is important for when the date in your dataset is only that, a date (no time associated). For example, this is really apparent in dropbox datasets (CSVs) contains a date "11/5/2016" but no time. We now allow you to choose this date field in the dropdown for Dropbox.
For API based default datasets, you will no longer see "11/5/2016 12:00:00" in drilldown or in the gauge builder when using this field type.
For Agent based datasets, in order to take advantage of this new field type, you will need the newest version of the agent. Version 4.04 which was released in October 2016. You can find access to that agent from your datasource page.
Now that we got that squared away, let's talk about building datasets and accounting for timezones per date/time field.
Timezones Per Dataset Date/Time Field
This one you'll notice whenever you build a new dataset or edit a current dataset. First, when you edit a current dataset that exists, you will see a new button that says "Configure Client & Date Columns" below sync history.
This button will take you to a modal where you can select both your Client Column AND new options for Confirming Timezones for date/time fields only.
By default, they will all be UTC because thats how people are currently building SQL datasets. That's where the change comes and where this gets technical.
Using the new Date/Time Fields to account for Daylight Savings changes.
Currently in your datasets we've asked you to do a timezone offset so that the time will come in UTC. Your SQL query will look like this for a Date/Time field.
In order to properly account for Daylight Savings Time changes, you have to strip off any timezone conversion in the SQL Query and just select the timezone per field in the modal I showed you above. That same line above will look like this now.
And when you save your dataset, you select which timezone that field is in. If its the same timezone as your current Account Settings, then just select "Use Admin Date Settings"
Believe it or not, that's it! Its a technical change but one that will help avoid any Daylight Savings data discrepancies.