Assuming that time formats (not timezone data, just plain-text Strings representing time in 12-hour clock), what is the best way to parse that data (examples below)?
I feel like this is a pretty simple question, but I've though about it a lot and can't figure out a fool-proof process for parsing out hour and minute values from any one of many time "formats".
I'm using a simple form that allows for entering a time (e.g., the time of a reservation), but there is no way to make the form field (Google Forms, limited customizability) anything other than plain-text which allows for any time format a person wishes to put in there a viable piece of data to work with. Here are some examples of times that can be entered:
1 P // hours would be 13, minutes would be 0
3:15 P.M. // hours would be 15, minutes would be 15
4 P.M // hours would be 16, minutes would be 0
8:30 a // hours would be 8, minutes would be 30
10:45 aM. // hours would be 10, minutes would be 45
12:00 Pm // hours would be 12, minutes would be 0
Those are just some examples. Feel free to fix tags if I'm not in the right topic(s) - I am however using Google Apps Script/Javascript to accomplish this.
I thought about building a couple regex strings to look for certain formats (which I'm sure will take me a while to write since I've never written one before).
I also thought about looking for a ':' character, and an 'a'/'A' character or 'p'/'P' for determing whether or not the +12 hours needs to be added. After that kind of information is retrieved the problem could be solved by truncating the 'p.m.'-type sections, then split(":") to get the correct numbers.
I feel like the first approach is much more stable, but the second solution might be easier. I'm not sure if there is a better way though, those are the two methods my n00b programmer mind could come up with.
I'm glad to hear you have an answer that you think will help you out. But before you write too much code, revisit this assertion you made:
...there is no way to make the form field (Google Forms, limited customizability) anything other than plain-text
Here's how you define a question to present a Date & Time picker, using the Forms UI.
The spreadsheet that is receiving your form responses will end up with a Date object - no need to mess around with strings at all.
Related
How can I modify a raw Unix timestamp so that it shows that it is 5 hours behind (as an example). I'm looking to do this with a javascript or python. The more lightweight the better. I'm basically looking for how to manually decode a given unix timestamp and change some of its numbers so that it gives me back a unix timestamp showing a different time. It would be even greater if I could automatically adjust it to a users personal time-zone using javascript/python.
Convert to the number of hours you want to offset by to seconds, and then add or subtract it from the Unix timestamp. As far as getting the user's personal time zone, I'm not sure how you would do that without language specific code.
How to choose a time 5 hours numerically smaller
This would be relevant for if, for example, you were testing whether the submission of an exam answer is within 5 hours of the exam's start time.
For this, just subtract 5 * 3600 * 1000 from the Unix timestamp's numerical value.
What you are actually proposing to do is extremely unwise
You seem to be planning to create a Unix timestamp of a different point in time which, when expressed as UTC but with the annotation "UTC" deleted, will match the local time display expected by a user who is 5 hours behind UTC. I can see why you are tempted to do this but it is a very bad idea.
Unix Timestamps do not default to be in UTC, they describe a point in time across all of space simultaneously. If you shift the value of a Unix timestamp, it is no longer a Unix timestamp, just as (mass of car minus 50 kg) is no longer the mass of that car. The value is either the mass of a different car that is 50kg lighter, or an incorrect value for the mass of the original car.
Unix timestamps are unambiguous. Once you know that a variable contains a Unix timestamp, you can stop worrying about any if's, but's or maybe's. It is solid and definite. What you are creating is a horrible thing which looks like a Unix timestamp of an timepoint, but it is not. What variable name are you going to give it to prevent confusion? You might give the physical property a new name, such as the goalieTimeStamp, which is distinguished from Unix timestamps by being displaced by 5 hours.
If a person is 5 hours behind UTC now (in January), that person will likely be a different number of hours behind UTC in summertime. This is a mess.
I think you are doing this so that you can display a local time nicely. Choose a different, better, way to achieve this.
You should use the localisation system in the relevant language to obtain and display the local time, which will depend not only on the location of the user, but also the time of year. This will also allow you to deal with languages etc, if you need to.
And throughout your code you will have a clear distinction between the timepoint of your event (invariant across space) and how a local user will express that time in their timezone, time of year and language.
A good library for this in Javascript is moment.js. It is rather heavyweight, but this is because the task is much more heavyweight that it first seems!
In a form, I'm asking for a start time & end time, which I'll be using in a script later on.
I figured in MongoDB, a time of day is best stored as the # of seconds since midnight (per How can I store time-of-day in MongoDB? As a string? Give arbitrary year/month/day?).
My question is: how can I display a human-readable time in autoform (e.g. 7:30pm) yet still save it as a number in mongodb & have proper client-side validation (make sure time is before 8:00pm)? I figure I could either use a datetime object & subtract the seconds since 1970, or I could parse the time string & do math on the hours, minutes, AM/PM.
Thoughts on methods? & where to put the math hooks in autoform? This seems like something folks a lot smarter than me have probably already figured out!
new Date(<unixTimeStamp>) will get you a javascript Date object which can be easily played with using libraries like moment (https://github.com/moment/moment)
Edit: also, to get the proper timestamp you can do +Date.now(). This jives with mongodb's date type
I am trying to store the time as a difference between 1 jan 2013 and the moment i save it on the database. It is definitely smaller than the standard of making it relative to 1970 ;) both in storage and because i am sending it clientside.
As I am going to do a getRelativeTime() quite a lot, I am looking for simplicity. I might change it from 1 jan 2013 to the date of server launch which is the 1st of a month in 2013 :D
I am keeping client and serverside track in GMT and it is on a nodejs server, the server is unknown. From what I researched, there are some solutions, but many call them incorrect due to this and that :|
To offer a valid answer to your question:
var ms = new Date() - Date.UTC(2013,0,1);
But PLEASE do not do this.
You will end up confusing anyone that uses your system (developers, api clients, database folks, etc.)
You will not be saving as much in terms of bytes as you think. JavaScript Number types are always 64 bits (8 bytes) in memory, see here. How much you might save in the database is very dependent on your database platform, but for example, the MySQL DATETIME type takes 8 bytes, while the TIMESTAMP type takes only 4. The range of a TIMESTAMP is much smaller, reference here and here.
You will probably encounter negative numbers frequently, if your app works with dates before your epoch. They will work, but they could be a source of confusion. If someone isn't aware of your adjusted epoch, they could produce a date that looks valid, but is supposed to mean something different.
You will also throw out any potential for using many great libraries that expect dates to work a certain way. You could convert to and from your custom date to a standard one, but do you really want to constantly wrap and unwrap those values? Probably not. Even libraries like moment.js that use their own types, do so by extending or encapsulating the standard data types. Compatibility is a much higher concern than byte space.
There are a lot of things wrong with JavaScript dates, but the choice of 1/1/1970 as an epoch was a good thing. Just because you can do something, doesn't mean that you should.
Also, consider that disk space is usually the least expensive component to running an application. Even with millions of records, you are likely to save a few dozen megabytes at most. Let's just error on the high side and say you save 200 MB with this clever hack. Amazon's top-tier provisioned IOPS cloud storage is $0.125 per GB per month. Congratulations, you've saved $7.68 over the entire year.
You are trying to normalize the value of epoch time? Epoch time as such gives in positive integer values. ain't it? 1356998400 is the amount of data you want to normalize.
I am looking for recommendations on displaying times in a web application in a time zone other than the user's current time zone.
We store our dates/times in UTC/GMT in the database, so it is not an issue to format the time for UTC/GMT or the user's current time zone. However, in other situations we need to display the time from the point of view of an arbitrary time zone (i.e. every date/time on this page is in Eastern, regardless of whether or not the user is in West Coast, Central, Eastern, etc.).
In the past we have stored offsets or time zone info, then done the calculations in server code in .Net or else we have done some client-side manipulations in javascript that I would prefer to avoid, since it all becomes very dependent on javascript and the user's browser. I'd like to know the best way to do this in a more client-side/MVC type application.
Here is an example:
Date stored in db: 1302790667 (Thu, 14 Apr 2011 14:17:47 GMT)
Converted date displayed for a client in Central time zone: Thu Apr 14 09:17:47 2011
Date I actually want to display, always in Eastern time zone: Thu Apr 14 10:17:47 2011
In the above example, it's easy to get the time in UTC (#1) or the user's current time zone (#2) but it is more difficult to get #3. My options seem to be:
Store offsets or time zones in the db and do calculations on the client - this is what we've done in the past with .Net but it seems even messier in client side code is the path we are currently trying to avoid.
Do the conversion on the server and send down a full date for display to the client - client receives a string ("Thu Apr 14 10:17:47 2011"). This works but it's not very flexible.
Do the conversion on the server, break it into parts and send those down to the client, then put them back together. ("{DayOfWeek:Thu, Month:Apr, Day:14, Hour:10, Minute:17}"). This gives us the correct data and gives us more flexibility in formatting the date but it feels a little wrong for this scenario.
Any other options ideas? How do others handle similar situations? Thanks.
Our results:
I tried out a few libraries like Datejs, MS Ajax, etc. and I was never very happy with them. Datejs didn't work at all in a few of my test cases, is not actively maintained, and seemed to focus a lot on syntactic sugar that we don't need (date.today().first().thursday(), etc.)
We do use jQuery for some basic date/time parsing.
I came across a lot of "roll-your-own" client-side date conversion "hacks", most of which only addressed the conversion to UTC, started off working fine, and then eventually fell apart on some edge case. This one was the 90% solution for a lot of standard UTC conversion but didn't solve our "arbitrary timezone" issue.
Between the code complexity the conversion routines added and the bugs they seemed to cause, we decided to avoid client side date processing most of the time. We do the date conversions on the server with our existing date handling routines and pass the formatted dates or info down as properties to be used by the view. If we need a separate date, we just add another property. There are usually only a few properties that we need at a time (i.e. EventDateUTC, EventDateLocal, EventDateAlwaysAustralia, and EventDayOfWeek).
I offer the suggestion that you look into the Datejs library. It offers a bunch of extensions to basic JavaScript date manipulation, including a "setTimezone()" method and flexible ways to convert a date into a formatted string for display.
I usually hesitate to suggest libraries when their use is not explicitly allowed for in questions, but Datejs isn't very large and it's pretty solid (even though it's called an "alpha" release). If you'd prefer not to rely on something like that, you might want to look at it anyway just to see the basics of how its extensions were implemented.
I'm adding a facebook feed to a jquery mobile application i am working on. I am trying to parse the "created_time" that is in the JSON data. This is what is in the returned JSON: 2011-01-29T16:30:03+0000. I would really love to have the data returned and displayed the same way that facebook has it. That would mean that if the post was less than an hour ago it would display as ## minutes ago, if it was more than an hour ago but less than a day ago it would display as ## hours ago, otherwise it would display as February 2 at 6:54pm. I would love some help with this! Thanks a lot!
Try pretty date from the author of jQuery. Available standalone or as a jQuery plugin.
By default it doesn't format dates older than a month, so you may want to edit this to ignore after X hours/days rather than months.