In a project we can create versions, but the release date format is just d/MMM/yy
Is it possible to have this display the time as well ?
Our datepicker properties are:
jira.date.picker.java.format d/MMM/yy
jira.date.picker.javascript.format %e/%b/%y
jira.date.time.picker.java.format dd/MMM/yy h:mm a
jira.date.time.picker.javascript.format %e/%b/%y %I:%M %p
we are running JIRA version 6.1.2, build 6157
realspirituals is right. With standard date field you won't be able to display a time.
Although opposing to the 'Configuring JIRA Options', I found 'Changing the Due Date Input Format', which states the possibility of adding a time component to the due date field. But I couldn't find something similar for Release Dates.
A similar feature request was raisied in May '13 to atlassian.
The only thing I can think of is to add metadata to your version and use a custom field to display it. See here: new field in version tab panel. This way you can further handle with it. If you just want to display the time and not "work" with it, just use the description field for that.
As per documentation
Date fields, which have no time component, such as due dates, release
dates (associated with versions) and custom date fields, solely record
date information (and no time zone-related information) so are not
affected by time zone settings.
My answer is Not possible and even if you print them, you should get 0's
Related
I have two tables in data studio:
I'm asking the user to select two dates to compare two weeks. This way, we can see the two weeks' data side by side. However, I also want to see the percentages of change based on vendor. Is there a way to show this? Or how can I improve the comparison method ?
note: vendor name field is not fixed. it can change for every week.
Data Studio provides a way to compare current date with previous one, but the comparison parameter will be fixed (eg. "current week vs previous week", "current month vs 2 months ago"). That means you won't be able to drop a selector for your users.
With this feature you to select the current date (or a range of dates) and it will always compare to the period you choose in design view. (I usually select the option "previous period", so if the user select a week, the comparison will be with the previous week; if the user select a month, the comparison will be with the previous month).
To achieve this, just check this entry in the documentation.
Another limitation is that it will always display the difference between current value and previous value (delta). Currently, you can't change this behavior.
For a monthly report need to display the months January to December in the value prompt. Could you please advise how to achieve this.
Welcome Immi
I do not know what data items are available on the package you are using
However, you can create static values with a value prompt
Look in properties for the value prompt, static. Select the ellipsis
Then add the values
Depending on the version of Cognos, you can search the data items (worst case do this manually, maybe you will luck out and there is a query subject for dates). Look around and see if months is in the package. If they exist, add them to the value prompt query subject and give it a try
Also to consider, your take may require 13 month accounting, displaying the month name won't work in that case.
As far as value prompts there is a display value and a use value
The month name can be the display value and if you need for filtering the month #, that can be the use value.
https://www.ibm.com/docs/en/opw/8.0.0?topic=prompts-adding-static-choices-prompt
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 speccing an application that displays time periods to the user. The goal is to present periods in a simple view (no time, no timezones) and detailed view (date and time, with timezone data). The simple view should be unambiguous, in other words the user can glance at it and their assumptions about what they see are correct (they are valid in the local timezone).
For the end of the global period, displaying the date in the AoE timezone [1] will solve this problem. For example, a submission deadline might display as 2018-04-03 (actually 2018-04-03 23:59:59 AoE). This means submissions are accepted as long as it is April 3 somewhere on the planet.
But I also want to indicate that start of a global period. For example, if submissions open on April 2 2018 00:01, they are accepted as soon as it is April 2 somewhere on the planet. (This would currently be at UTC+14, matching the Line Islands.)
I can't see a way to use AoE to derive a global start time. Is there an equivalent to AoE (a standardized semantic timezone) that tracks the global start time?
Notes:
Hardcoding UTC-12 and UTC+14 is the simple answer for the modern day. But I'm looking for semantic timezones that would be updated if the values changed (and not reference non-existent historical datetimes).
I thought I'd seen Etc/AoE in the tz database but this is not the case.
References:
AoE
UTC-12:00
UTC+14:00
[1] The Anywhere on Earth (AoE) timezone represents the moment a datetime expires "anywhere on Earth". It currently matches time at Howland Island (UTC-12). If a UTC-13 timezone were invented, it would be updated to track that.
As far as I could understand, AoE is not a timezone as defined by IANA (AFAIK, a list of all offsets from some geographic region during history).
It's more like a "concept", an idea of a specific date being valid in any place on earth. As you said, this notion of "being valid" will change if more timezones are created or removed.
I don't even know if date/time API's can properly handle AoE automatically - maybe I should study more. But my conclusion is that the only way to achieve your goal is to check manually:
you could check all available timezones and see if the date is valid there, comparing to the current date/time at that zone
you could configure the UTC+14 as the offset to be compared, and make some scheduled job (daily/weekly/every-time-IANA-publishes-a-new-version?) to check all zones and set the correct one (with the biggest offset?). You must also take care if this zone has Daylight Saving changes, because the offset will change as well (and what to do with overlaps, when clocks shift 1 hour back and a local time may exist twice?)
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