Hot answers tagged

8

Use the ISO format for combined date and time values. It's best to stick to the standards, especially when dealing with dates. The above linked Wikipedia article states (emphasis mine): A single point in time can be represented by concatenating a complete date expression, the letter "T" as a delimiter, and a valid time expression. For example, "2007-04-...


3

Another way is to change the format of the UI when the end date is not defined. Instead of displaying: March 1, 2019 - N/A you can have something like: Starting from March 1, 2019 If you think this may confuse the user, you could easily add an element that clears the confusion when hovered over, like this: Starting from March 1, 2019 (?)


3

From a user's perspective, it will be very helpful to provide an overview of what times are available (think also of the way many cinema/theatre sites show a visual seating plan when booking tickets). As a starting point, you should be looking for something along the lines of the following, where they can both see what times are available, and pick the one ...


2

In your question, you say it's an error "...if the user enters a future date." So, tell the user that's what happened. Date of birth cannot be a future date.


2

These timestamps should be very rare; it's just one hour in the 8760 which happen in a year's time. The hour is deliberately chosen in the night, so most people not familiar with UTC (programmers, system administrators, astronomers, military) don't need to register anything in that hour. That said, one option might be that when a user enters an ambiguous ...


2

The vacancy period here is quite hard to define unless you have a start and an end. If there is no end date then it's not a period but a state. Therefore I suggest splitting the logic here into two parts: Vacant state (on / off) Dates for when state is known So the dates would be : Vacant from: "" Residents will return: " " (unknown return date). If ...


2

I take it this is unambiguous to a human reader rather than a machine? The ISO 8601 is a good suggestion for machine readable/parseable data, but for human readability it's trickier. E.g. the US does dates with months and days swapped round, so in your example do you mean the 5th December or the 12th May? That's bit me a few times in the past - while the ...


1

I tend to lean toward ISO, but with file-naming limitations, the benefits of sorting, and yet still relatively human friendly, for your use case, I'd actually lean toward something like: 2020y01m14d_12h30m11s_8765ms-23hrs-UTC.log 2020y01m15d_12h31m11s_7654ms-23hrs-UTC.log 2020y01m16d_12h27m11s_9867ms-23hrs-UTC.log 2020y01m17d_12h41m11s_5432ms-23hrs-...


1

I prefer to represent all of data in 2 digits as follows, 20Y02M14D12H30M11S86SS75MS.log But if you have to keep year and millisecond in 4 digits then you might use the following one, 2020Y02M14D12H30M11S8675MS.log


1

I made a mock up just for a reference for the structure since I saw that it was your main concern. It's important that you show some visual clue in the calendar to different days with/without available hours so the user does not click there in vain. Hope it helps.


1

Disable future dates in the calender input control.


Only top voted, non community-wiki answers of a minimum length are eligible