I have 3 steps, each step is its on view. On step 1 I ask for the start date/time(they can pick timezone and time) and store it as UTC, on step 3 I want to show the date/time based on the timezone they selected, without knowing which timezone they selected (don't store it, as users see it based on the computer timezone).
I want to know the best way to do this. I was thinking storing the tempdata, and then re-storing it. Though it doesn't seem like a best practice.
If the model(s) you use for steps 2 and 3 have a Timezone property, you could store the value in a hidden field and have it posted back to you, like this:
Html.HiddenFor(model => model.Timezone);
Alternatives would be putting the value in a cookie (and perhaps then using a CookieValueProvider to get it back) or putting it in session, although the last option isn't really how MVC is 'meant' to be used.
Related
My app lets people log the movies they see (for example). Each logged movie usually (but not always) has a date and sometimes has a time. It's not unusual to have one but not the other. Occasionally the dates are only a year ("I watched a Dumbo sometime in 1984"), but could realistically be any combination of day/month/year/time.
I am used to modeling dates as date objects in my app and my backend. But is it a viable approach to store each component separately? When I need to reference an actual date from the components (e.g. for sorting the log) this will be built client-side, or perhaps be stored as a derived property sortDate and updated whenever any of the components change.
My reservation is that the information the user is saving is truly a 'moment in time' and I will have to take care of some things myself - for example what time zone are my components stored relative to? This would be captured automatically as part of a real Date object.
The alternative seems to be assuming some sort of 'default' for missing components (e.g. year 0000 if no year, time 00:00 if no time). But those defaults have meaning and I won't be able to distinguish them from 'not provided'.
What are the limitations and/or pitfalls of this approach? Does anyone have experience modeling their dates this way?
If it's of any consequence, my app is for iOS written in Swift and uses a Parse Server backend.
I've successfully used question marks to represent ambiguous and unknown timestamp parts in legal systems. Try to keep in mind that you're really not modeling dates here ('1984' isn't a date); you're modeling facts about dates.
So, if one of your users saw a movie some time in 1984, you might record the value '1984-??-?? ??:??:??' in a text column in a database. Values like this sort sensibly.
See also this answer on dba. Comments on that answer are also good to read.
I'm writing a room booking system in .net Core 2.0
I have StartTime and EndTime stored as DateTime variables, but the built-in HTML datetime field is clunky and rather user-unfriendly, so I want the values to display on the page as a date field and a time field.
But I'm wondering what the best way of implementing this is. Should I:
create some readonly variables within the model (can I do this without creating database fields?)
create the separate form fields (with jQuery datepicker) and then use JavaScript to write the values of the inputs to hidden fields which store the full DateTime?
(NB I haven't chosen to change the database fields because it is conceivable that a booking might run past midnight. The JavaScript would assume that an early hours endtime is the next day. )
First and foremost, use DateTimeOffset instead of DateTime for your database-backed date/time properties. Whether you end up storing the values in UTC or local time, as long as you have the timezone, you can get to whatever other locale you need. Trust me, this will be invaluable in the long run.
As far as editing goes, make your inputs datetime-local types. This isn't actually supported by any browser, but it at least carries more semantic value and who knows, maybe one day browsers will finally get off their collective hind-quarters and do something with it. Breaking it out into separate date and time fields is tempting, so that you can take advantage of built-in browser controls, but it's clunky and prone to error. Use a JavaScript library that provides a good date and time control to progressively enhance the input instead. My favorite at the moment is air-datepicker. It's lightweight, supports all sorts of scenarios and configuration options, and it's localized.
I'm using Rails 4, and also Twitter Bootstrap.
I'd like to select the date with a date picker, but have a separately visible component for selecting the hour and minutes.
I've had a look at smalot bootstrap-datetimepicker https://github.com/smalot/bootstrap-datetimepicker , but looking at the Demo Page, they don't demonstrate any ability to show date and time separately. You have to choose date, and then later on choose time, which doesn't feel very intuitive.
I've also looked at Eonasdan bootstrap-datetimepicker https://github.com/Eonasdan/bootstrap-datetimepicker , but the time picking for it, even in inline mode, is not intuitive - will people know they can just click on the hour value to change it?
I'm thinking of just using a date picker for picking the date, and selecting the hour and minute myself, but it kind of feels wrong handing off part of a datetime to a gem/library and handling the rest of it myself.
I came across Separate date and time form fields in Rails , which is asking about this kind of problem, but it's a question from September 2010.
How do I select the date with a date picker, but have simple and immediately visible selection of time?
First, unless you find a plugin that does what you want off the rack, then yes, it's up to you to handle it, and yes, it feels kinda wrong - depending on how you do it.
Not sure what you had in mind, but the way it feels "the most wrong" is if your form has a single "date time" field under the hood, and you use javascript to botch together the date from the plugin and the time from your own setup, and store them in your datetime field. The nice thing about this is your rails app just gets a single datetime field and knows exactly what to do with it.
Here's how I'd approach it:
Keeping in mind that forms don't necessarily have to map 1-to-1 with your models, I'd split it in the controller layer, and conceptually think of "a form with two fields: date, and time", and then in your controller (or a form object, which is probably better for this situation) you'd stitch the date and time together, before saving them to your model. This approach means you can have separate validation on each field, which is probably also what you want (because I'd assume it's possible for users to input a valid date, but an invalid time or vica versa).
In terms of handling the date with a plugin and the time yourself, that's now fine - they're two completely separate fields from the perspective of your form, so there's nothing dirty about it. It just means you need the extra logic in your controller layer to split the datetime when you display the form, and merge the date and time back into one when you save the form.
Edit: if you haven't heard of form objects, check out https://github.com/apotonick/reform and http://railscasts.com/episodes/416-form-objects
I am to store quite large amount of boolean values in database used by Rails application - it needs to store 60 boolean values in single record per day. What is best way to do this in Rails?
Queries that I will need to program or execute:
* CRUD
* summing up how many true values are for each day
* possibly (but not nessesarily) other reports like how often true is recorded in each of field
UPDATE: This is to store events that may or may not occur in 5 minute intervals between 9am and 1pm. If it occurs, then I need to set it to true, if not then false. Measurements are done manually and users will be reporting these information using checkboxes on the website. There might be small updates, but most of the time it's just one time entry and then queries as listed above.
UPDATE 2: 60 values per day is per one user, there will be between 1000-2000 users. If there isn't some library that helps with that, I will go for simplest approach and deal with it later if I will get issues with performance. Every day user reports events by checking desired checkboxes on the website, so there is normally a single data entry moment per day (or few if not done on daily basis).
This is dependent on a lot of different things. Do you need callbacks to run? Do you need AR objects instantiated? What is the frequency of these updates? Is it done frequently but not many at a time or rarely but a bunch at once? Could you represent these booleans as a mask instead? We definitely need more context.
Why do these need to be in a single record? Can't you use a 'days' table to tie them all together, then use a day_id column in your 'events' table?
Specify in the Day model that it 'has_many :events' and specify in the Event model file that it 'belongs_to :day'. Then you can find all the events for a day with just the id for the day.
For the third day record, you'd do this:
this_day = Day.find 3
Then you can you use 'this_day.events' to get all the events for that day.
You'll need to decide what you wish to use to identify each day so you query for a day's events using something that you understand. The id column I used above to find it probably won't work.
You could use the timestamp first moment of each day to do that, for example. Or you could rely upon the 'created_at' column of the table to be between the start and end of a day
And you'll want to be sure to thing about what time zone you are using and how this will be stored in the database.
And if your data will be stored close to midnight, daylight savings time could also be an issue. I find it best to use GMT to avoid that issue.
Good luck.
I'm working on a Rails application that allows users to define Tasks, which require a due_date. The due_date may or may not include a time.
The way we're handling this right now feels like a hack. due_dates default to 12:00 AM, and in that case we don't display a time. The DateTime object doesn't allow for empty Time values as far as I know.
Should I split this information up into two columns in the database? How do you guys handle this?
Since your data structure needs to accommodate dates with and without a time, you have two choices:
Use a Ruby DateTime object with a flag value for the time to indicate that the date does not have a time. The usual flag value for this is 0 which then means the midnight time can't be shown. (Midnight is 0 seconds after the day has started.)
For example, parsing "Jan 1, 2010" into a DateTime will give you Jan 1, 2010 00:00.
Otherwise you'll need to invent your own data structure. Easiest would probably a Class with a DateTime and a "show_time" boolean flag. -- by using a DateTime to hold the time, you'll be able to use the DateTime output methods, and do arithmetic with them if needed.
Creating a new data structure is not such a big deal in Ruby, but if you can live without tasks due exactly at midnight, I'd recommend method 1. Note that you'd probably want to print them without a time since that's what the task definer requested. Or you could include "(any time)" in the output.
PS
Watch out for timezones! Many ways to handle, but you should be sure to choose one deliberately.
Splitting the attributes may be unnecessarily complex. Why not adopt a convention that if no time is specified then default it to midnight or noon on the date in question? Unless you need to be able to distinguish between the two cases, i.e. this is midnight because it was explicitly specified or this is midnight because no time was specified. If the latter then splitting them might be advisable or just add a boolean to disambiguate the cases.
If you thought you had further use for a separated date and time and would expend lots of energy splitting a single field for other reasons then that might also argue for splitting.