Hi I hope this is a simple question but it has been bugging me for quite some time. I have a Date Picker and a Time Picker. How do I save (or combine) the Date and Time into one entry in the database. Basically right now I have June 22, 2020 and I have 4:00 PM as two separate entries. How do I save them as June 22, 2020 4pm?
@keith I really appreciate your video. I feel like it would be really helpful if @emmanuel or someone from Bubble put together an official video or lesson on how time works in Bubble. I think its a pretty big topic (hence why @keith made the video) that is difficult to understand with current Bubble documentation.
I am using a number and a text value because the text values are used for the display of the time. Numbers are used to calculate the total minutes and total seconds to help with sorting but also to turn dates to be stored with selected times.
In practice, once the user has selected the time, if I want to attach it to a date, I do, by simply using some date value and changing the hour, and minutes values to equal those selected in the Time Picker
which gives me a total time elapsed in minutes. I then build my dashboards to take those calculated fields and do averages or whatnot. A bigger problem is that my times often cross different days (one common example is length of stay - which I calculate in hours because I have different reporting requirements if that is
Here is a thread that has a lot of time based solutions. Feel free to browse through them (I think there are currently 5 pages). If you can't find exactly what you need or need help adapting a solution to fit, feel free to let me know, and we can walk through some things together.
@Cody Staub Smartsheet does not currently have time formatting/functions/calculations built in, but from my understanding they are working on it. In the meantime that means we are stuck with using workarounds. You have already cut out some of the more complicated bit by using 24 hours times.
Thank you for the input. I think I changed the formula to match your feedback. On the date overlap piece...my data sometimes includes a date overlap, but not always. I need my final formula to work with either scenario.
One possibility would be a setting on the field that doesn't show the time portion of the date - anywhere in pro, attribute table, selection clauses etc. Maybe with this setting the time it defaults to 12.00am even when you use the 'Today' feature of the date picker.
It just seems to me that more often than not the time feature that is entered into a feature class is generally not needed. I understand in some circumstance it is but generally speaking it's too precise for any real use and it would be good it this information was not shown to users.
In ArcGIS Pro 2.3.2 it looks like in the attribute table, if you don't set a specific time (as you noted above as the 12am default time) it does not display in the table. When a time is specified, it displays along with the date.
Yeah I realise that if you have 12am as the time it doesn't show but if you just hit 'Today' it automatically puts in the current time. Knowing our users they are not going to be bothered to change the time to 12am - but they will complain that the time is showing when it means nothing to them.
It's not that I care if the time is stored in the database or not - it would be cool if you could have a Date field and a DateTime field so you could choose which one you wanted - but I haven't seen that on any database and since we are using SQL Server I'm guessing that is controlled by the database. But it would be cool if you could could control if the time portion (or any portion - maybe you just want month and year) of the date is showing or not.
Looks like maybe starting at Pro 2.4 choosing today does automatically set the time to 12am instead of the current time, meaning that what is displayed in the attribute table is just the date and not time...
Hi @MicheleH1_DNReply I ran across this idea this morning and wanted to share that in Pro 2.8 you can apply a date format to fields. See -app/latest/help/data/tables/format-numeric-and-date-fields.htm#GUID-04...
That will be helpful in the cases where we have created a template project and people are creating a copy of that to do their work. Unfortunately this only covers a couple of scenarios. In most cases people are creating their own projects and pulling the data in fresh each time so if the setting isn't a global ArcPro setting or set in the database (sql server) itself then this doesn't help much. I can however let people know that is there whenever they whinge at me!
Thanks for the clarification, @MicheleH1_DNReply So for an individual user, it is possible to set the date time format as needed, but you are looking for a way to set that at the application level and deploy to your organization. I added a comment over here: -pro-ideas/migrating-arcgis-pro-options-settings/idc-p/1106396#M...
For dates before 1900, there is a several minute difference between ArcGIS Pro and ArcGIS Online. Dates in the 1800s which are stored at 12:00 AM in a feature class in ArcGIS Pro appear as 12:03 AM when published to a feature service. I understand this is a known issue with historic dates in ArcGIS and Microsoft Office, but there should be a way to remove timestamps, especially for historic events where only the date is recorded.
It's also important to be able to remove time to ensure that the date is correctly displayed, because ArcGIS Online displays time in the time zone of your computer. That means that dates saved at 12:00 AM in ArcGIS Pro and published to a feature service set to UTC time appear as 7:00 PM the previous day on a machine in Eastern time and 4:00 PM the previous day on a machine in Pacific time. I understand this is expected behavior and makes sense for current data, but doesn't make sense for historical data where users anywhere in the world should be able to see the same date for a historic event. Showing dates on the previous day in ArcGIS Online and different dates based solely on the user's location is misleading.
My data is collected monthly (on the last day of the month). The DD value is always 28, 29, 30 or 31. I would like to use the Space Time Cube with a time step of 1 Month(s). Upon using some of the other tools this week, I realized I should not have been so quick to disregard the warning messages that came when I initially created the space time cube.
I've tried the changing my date format into yyyy-mm-dd format (and other formats), but upon importing the CSV, the date is automatically switching back to mm/dd/yyyy. The ESRI videos online seem to indicate that mm/dd/yyyy date format is fine. The date field is recognized as a date field and I have no issues selecting the Time Field within the Create Space Time Cube tool.
I don't think the problem is the date format. I think the problem is that you have incomplete data. Check to make sure you have a data value for every month, for every well. If you are missing just a few data entries here and there, the Fill Missing Values tool may be able to estimate the missing data. I'm pretty sure (not positive) you would still need, at minimum, a data entry for the first and last month for every well. I hope this helps!
Thank you! I did have a lot of missing data, maybe a little too many to handle by using filling empty bins with zeros within the Create Space Time Cube geoprocessing tool. I was successful after truncating my data to a more "complete" time interval.
With sufficient knowledge of applicable algorithmic and political timeadjustments, such as time zone and daylight saving time information,an aware object can locate itself relative to other aware objects.An aware object represents a specific moment in time that is not open tointerpretation. 1
A naive object does not contain enough information to unambiguously locateitself relative to other date/time objects. Whether a naive object representsCoordinated Universal Time (UTC), local time, or time in some other timezone ispurely up to the program, just like it is up to the program whether aparticular number represents metres, miles, or mass. Naive objects are easy tounderstand and to work with, at the cost of ignoring some aspects of reality.
For applications requiring aware objects, datetime and timeobjects have an optional time zone information attribute, tzinfo, thatcan be set to an instance of a subclass of the abstract tzinfo class.These tzinfo objects capture information about the offset from UTCtime, the time zone name, and whether daylight saving time is in effect.
Only one concrete tzinfo class, the timezone class, issupplied by the datetime module. The timezone class canrepresent simple timezones with fixed offsets from UTC, such as UTC itself orNorth American EST and EDT timezones. Supporting timezones at deeper levels ofdetail is up to the application. The rules for time adjustment across theworld are more political than rational, change frequently, and there is nostandard suitable for every application aside from UTC.
An abstract base class for time zone information objects. These are used by thedatetime and time classes to provide a customizable notion oftime adjustment (for example, to account for time zone and/or daylight savingtime).
Changed in version 3.2: Floor division and true division of a timedelta object by anothertimedelta object are now supported, as are remainder operations andthe divmod() function. True division and multiplication of atimedelta object by a float object are now supported.
df19127ead