Does anyone know if there are names for certain types of formatting of time's and dates like
h:m:s:ms
xh xm xs xms
etc?
I would like some way to describe these different formats for an enumeration to pass to a formatter.
Related
For standard ones I find it pretty straightforward
NumericRangeQuery.NewIntRange(item.Name, item.MinValue, item.MaxValue, true, true))
It works great with most common numeric types.
But what I would like to do is to make a range query with such datatypes as Date and decimal.
How could I achieve this?
For dates, store them as ints. So 2016 July 23 = 20160723
If you want to the hour or minute or second, just add those digits to the right. You may need to switch to long (Int64) for the longer versions.
If you want finer grain then store Ticks.
After all that just use the appropriate NumericRange query.
In Lucene.net 3.0.3 the best float accuracy is with Double
I have records in Amazon's cloudsearch that are timestamped with an int representing milliseconds since the epoch. I call the field time. This can be negative for dates before 1970. When I perform a structured query using time:[0,}, it's returning negative as well as positive timestamps, which is wrong. The docs say that ints are 64-bit signed, so I don't see why this wouldn't be valid. My query syntax works fine with other fields that are only positive-valued. Are range searches actually restricted to positive numbers?
(aside: I know I could use a date string format, but I want to use an integer for consistency with other parts of my system. Also I want to be able to represent BCE dates and I'm not sure whether YYYY:MM:DD formats behave safely when YYYY is negative.)
It turns out Cloudsearch queries work fine with negative numbers, as you'd expect. My problem was that I'd previously defined this field as a text field (and a text comparison won't numerically order strings like '123', '-555', '-1', etc.) I'd changed the field to an int, but I'd forgotten to re-index, so Cloudsearch was still secretly treating it as text.
To re-index after changing field types you can use:
aws cloudsearch index-documents --domain-name mycloudsearch
or you can do it from the web interface.
I have a string in the following format:
14:41:21 Dec 15, 2015 PST
I want to convert that to my server's local time, but I think I'm creating an extra step that can be avoided:
Dim testdate As Date
DateTime.TryParseExact(dateinput, "HH:mm:ss MMM dd, yyyy PST", CultureInfo.InvariantCulture, DateTimeStyles.None, testdate)
testdate = TimeZoneInfo.ConvertTimeToUtc(testdate, TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time"))
testdate = testdate.ToLocalTime()
I've played around with this but always off by a couple hours either way, and the above is what I've found to work but just wanted to know if there was a better way. Also note it could be deployed on multiple servers, so I don't want to specify the timezone to convert it to explicitly, reason for localtime.
A few things:
If you're going to include fixed text in a format string, put it in single-tick quotes so it can't get misinterpreted as a formatting token. ('PST')
In the general case, time zone abbreviations should only be used for display purposes. They should not be parsed as input, as they could be ambiguous. For example, there are 5 different interpretations of CST. It might be US Central Standard Time, but it could also be China Standard Time, or one of the others. See the list on Wikipedia.
If you have a limited number of time zone abbreviations you want to support, then you could extract it from the string and use a dictionary, select/case statements, or conditional logic to map them. Just be certain you know the entire set of abbreviations you want to support and exactly which time zones you want them to map to. Also be sure to account for daylight time abbreviations, such as PDT.
Note that some older standards, such as RFC 2822 §4.3 indeed hardcode a few abbreviations, so you may choose to support those if you are parsing that particular format. (Yours is similar, but not quite a match.)
Your code is mostly ok, but you should probably check the result of TryParseExact. Otherwise you might as well use ParseExact which will throw an exception on failure instead of just returning false.
You could use ConvertTime with TimeZoneInfo.Local as the destination zone if you wanted to do the conversion in a single step. The code would be slightly smaller, though would have no technical differences.
Are you sure you really want to do this? Relying on the system's local time zone should usually should not be done in server-based applications. That's something more appropriate for desktop and mobile. In general, server-side code should not rely on the system time zone to be anything in particular. Avoid "local time" APIs, including DateTime.Now, TimeZoneInfo.Local, ToLocalTime, and ToUniversalTime (when it assumes the input is local time). It is better to supply the applicable time zone in your business logic or application configuration.
I've got two NSDate, date and time. I'd like to add them in such a manner that I get the date from date and time from time. Any suggestions on how I do this?
Cheers
Nik
If I got you right NSDates -dateByAddingTimeInterval: together with -timeIntervalSinceDate: are what you looking for.
hth
–f
Use NSCalendars components:fromDate: to get the components of the two dates.
Then reassemble them as needed using dateFromComponents:.
I've got two NSDate, date and time.
Sounds like you're going about it wrong.
An NSDate represents a specific moment in time (X seconds since the epoch). An NSDate is not simply “x o'clock” or “this date on the calendar”, and you shouldn't attempt to combine them as if they were because effects such as DST may make your computation wrong (in some time zones, some dates have two 1:00 hours, and some have no 2:00 hours).
Consider using an NSDatePicker or UIDatePicker (as appropriate) to let the user enter the date and time from a single place. Not only is this easier for you to do, it'll also give more correct results.
If you're reading the two pieces separately from a file or similar source, and you don't control the format (so you can't order the generating side to emit dates with their times in one value), you'll need to do one of two things:
If possible, combine the two strings. For example, an ISO 8601 date (e.g., “2010-05-10”) and an ISO 8601 time (e.g., “23:20:19-0700”) can be concatenated with a ‘T’ between them to form a valid, fully-specified ISO 8601 date (“2010-05-10T23:20:19-0700”). You can then pass this single string to a properly-configured NSDateFormatter.
If, for some reason, you can't combine the strings meaningfully, parse them yourself and fill out a single NSDateComponents object yourself.
This will not be pleasant, but correctness is important, and a bug (incorrect date parsing) that only happens in two hours out of every year for only some of your users will be maddening.
The goal is to produce exactly one NSDate object that completely describes the date and time in question. This is the only way to ensure that, in all circumstances, you get the correct NSDate value.
Is there a list of best practice MySQL data types for common applications. For example, the list would contain the best data type and size for id, ip address, email, subject, summary, description content, url, date (timestamp and human readable), geo points, media height, media width, media duration, etc
Thank you!!!
i don't know of any, so let's start one!
numeric ID/auto_increment primary keys: use an unsigned integer. do not use 0 as a value. and keep in mind the maximum value of of the various sizes, i.e. don't use int if you don't need 4 billion values when the 16 million offered by mediumint will suffice.
dates: unless you specifically need dates/times that are outside the supported range of mysql's DATE and TIME types, use them! if you instead use unix timestamps, you have to convert them to use the built-in date and time functions. if your app needs unix timestamps, you can always convert the standard date and time data types on the way out using unix_timestamp().
ip addresses: use inet_aton() and inet_ntoa() since it easily compacts an ip address in to 4 bytes and gives you the ability to do range searches that utilize indexes.
Integer Display Width You likely define your integers something like this "INT(4)" but have been baffled by the fact that (4) has no real effect on the stored numbers. In other words, you can store numbers like 999999 just fine. The reason is that for integers, (4) is the display width, and only has an effect if used with the ZEROFILL modifier. Further, this is for display purposes only, so you could define a column as "INT(4) ZEROFILL" and store 99999. If you stored 999, the mysql REPL (console) would output 0999 when you've selected this column.
In other words, if you don't need the ZEROFILL stuff, you can leave off the display width.
Money: Use the Decimal data type. Based on real-world production scenarios I recommend (19,8).
EDIT: My original recommendation was (19,4); however, I've recently run into a production issue where the client reported that they absolutely needed decimal with a "scale" of "8"; thus "4" wasn't enough and was causing improper tax calculations. I now recommend (19,8) based on a real-world scenario. I would love to hear stories needing a more granular scale.