I've been looking into Koa.js recently as a next-gen option for running a server (looks good so far...) and came across the following code in an API example:
function *reqlogger(next){
console.log('%s - %s %s',new Date().toISOString(), this.req.method, this.req.url);
yield next;
}
Most of this code looks pretty good, but I'm not sure whether to leave toISOString() in. The first console.log parameter(s) is formatting the result as string(s) anyway, so why would I want to bother converting the string to ISO format?
Are there any additional benefits I might see down the line to declaring like this? Are there particular functions that prefer date objects in ISO format, for example, or is it just a matter of personal preference?
Related
I have a problem with 2 lines of code, which don't work as I expect. The point is that the DateTime object is being converted to string and back to DateTime, using default conversion, without explicit format specification.
$timeString = [DateTime]::Now.ToString() # contains 17.01.2017 20:01:30
$time = [DateTime]$timeString # PS blows with error
So, basically, it uses the default date format to format the string, but then it seem to use some other format to parse it back. The following line of code will work, however:
$otherTime = [DateTime]"01/17/2017 20:01:30" # will get the initial date
Could someone point me to proper documentation on the matter of types conversion, and why in this case it would use different formats to convert data back and forth?
Thanks in advance.
Parsing dates is always a nightmare. Especially if you live in the tiny part of the world that is called 'outside US' :)
In general formatting and parsing dates in .NET (and many other things as string comparison) are controlled by culture settings. In some cases then default behavior is to use the current culture settings. Convert.ToDateTime is one of them. If you take a look into the documentation (Convert.ToDateTime Method (String)) it says:
If value is not null, the return value is the result of invoking the
DateTime.Parse method on value using the formatting information in a
DateTimeFormatInfo object that is initialized for the current culture.
The value argument must contain the representation of a date and time
in one of the formats described in the DateTimeFormatInfo topic.
That's why it converts from your localized date string. In other cases the default behavior is to use the 'Invariant Culture' setting which usually means 'US settings'. Most of the methods are overloaded and can take a parameter that specifies the culture that should use, but it requires a little search into the .NET documentation.
As a rule of thumb: Don't use strings that are localized if they are not going to be shown to the end user. Always try to find the 'Invariant Culture' variant of the method, and use it for formatting and parsing of the strings. It will save you from many headaches.
You're implicitly calling Convert.ToDateTime(String), but this method's valid formats are hardcoded (and don't appear to be listed). From your output date format, I see that you're likely not in the US, which is probably what most of the formats are centered towards.
Instead, you can explicitly use Convert.ToDateTime(String, IFormatProvider) to tell it which culture format provider you want.
[Convert]::ToDateTime($timeString, [System.Globalization.DateTimeFormatInfo]::CurrentInfo)
I'm on a US system, so I'm not entirely certain if this will work yet.
You can also use [DateTime]::TryParse() or [DateTime]::TryParseExact() to explicitly specify the format(s) you want.
I am asking for gplex, however it might be the case, the solution to the problem works for other lex-derived tools.
I wrote all rules, everything is fine with one exception. The type of the scan method of the generated scanner is int, and I would like to be MySymbol (which would consist of id of the token -- INT, STR, PLUS, so on, its value, and possible location in the file).
I checked the samples (not many of them), but they are very simplistic and just write out the fact rule was matched, I've read the manual, but it starts from parser perspective and for now I am a bit lost.
One of my rules in lex file:
while { return new MySymbol(MyTokens.WHILE); }
All I have now is scanning phase, I have to finish it, and then I will think about parser.
Yacc and Yacc-like tools (here GPLex) relies on side effect. Normally you could think of returning the data, but here you are returning token id, and any extra data has to be "passed" via special variables like yyval.
If I'm using this:
DateTime.Now.Date.ToString("yyyy-MM-dd")
FXCop complains that I'm violating CA1305 and says that I should provider an IFormatProvider. Do I need to? I'm asking for the date in a specific format anyway (which is the format I'm expected to put it into the XML as).
Would providing a format provider make any difference? Might it actually produce the wrong results in this case?
Why don't you want to specify the format provider?
If it is just laziness then I can recommend defining two snippets. ic for CultureInfo.InvariantCulture and cc for CultureInfo.CurrentCulture.
Never assume anything about how conversion to string works with the default culture. Not everyone in the world uses the gregorian calendar. Some day you customer might hire a contractor with a computer with another calendar as default and then you are not generating correct XML. Explain then to your customer that you didn't want to follow the FxCop recommendation.
Best thing would be if .Net included a Xml Culture. Then you could just do
DateTime.Today.ToString("d", CultureInfo.Xml)
For some reason Microsoft choose to create a separate class instead XmlConvert. The class has been there since .Net 1.0.
XmlConvert.ToString(DateTime.Today, "yyyy-MM-dd")
will always create a correct Xml date.
Not sure if it is bug or intended behaviour but XmlConvert.ToString(DateTime.Today, "d") will not create a valid Xml date.
so after a bit more research it seems that in my instance it doesn't make any difference, but in the general case months might be displayed in a specific locale.
More details here:
http://msdn.microsoft.com/en-us/library/8kb3ddd4.aspx
I always gets confused when I deal with Classes and Objects. As I am trying to understand the Spreadsheet::ParseExcel module, I am having some doubts for its classes and object :
My doubt is:
With $parser= Spreadsheet::ParseExcel->new();, we are creating an object for Spreadsheet::ParseExcel and after this we shall create the object for Spreadsheet::ParseExcel::Workbook.
Why can not we create the object directly for Spreadsheet::ParseExcel::Workbook and start parsing ?
Thanks
Why can not we create the object directly for Spreadsheet::ParseExcel::Workbook and start parsing
That is a reasonable question and in older versions of Spreadsheet::ParseExcel there was a Spreadsheet::ParseExcel::Workbook->Parse() method that did just that. (*)
Users tend to see an Excel file only as a workbook. However the file format also contains data such as metadata (author, creation date, etc.) and vba macros that are separate from the workbook data.
As such the logical division of the parser from the workbook probably occurred due to the physical division of the data in the file.
Or it may have been to allow reporting of file parsing errors rather than just returning an undefined workbook object.
Either way, other people may have chosen to model the interface differently but that is what the original author chose. It is not completely intuitive but it works.
(*) This method is now deprecated since it doesn't allow error checking on the file.
Think about Spreadsheet::ParseExcel and Spreadsheet::ParseExcel::Workbook like they are just of different types, like integer and string, which are both scalar, but you cannot, say, multiply them, although they can interact in some cases. E.g. length() applied to string gives you integer length of string. The same way, Spreadsheet::ParseExcel::parse() gives you Spreadsheet::ParseExcel::Workbook. They are bound by common namespace but they are completely different, Spreadsheet::ParseExcel is a parser and Spreadsheet::ParseExcel::Workbook is a workbook.
I've inherited an iPhone app that has a file containing all code necessary to perform API calls to our server (ServerRequests.h/m).
All endpoints for the API are buried within the various methods, and I'm looking for a way to refactor these endpoints out into their own separate file, or at the very least declared constants at the top of this file.
The problem is portions of the API endpoints are variable, such as user_id, photo_id, etc.
Am I amble to store a format string as constant and then have the variable portions replaced at a later time?
If not, do you have any suggestions about how to manage my API endpoints in a better way than just strewing them all throughout a file?
Thanks!
If I understand your need, something like this might work for you:
#define SOME_ENDPOINT #"what/ever/%#/you/need"
At the point of use, you use string formatting to get the final string:
[NSString stringWithFormat:SOME_ENDPOINT, user_id, ...];
IOW the majority of the string is stored in a constant that is a template used as the format spec for formatting the final string.
Is that what you want? Or need something 'fancier'? There is a feature of Python that I miss in Obj-C - you can have 'named' specifiers in the format like #"some/%(user_id)s/etc/etc/" and when you perform the formatting, you supply a dict(ionary). The 'user_id' spec is used as a key to find the associated value, which is then formatted (e.g., using the 's' spec in my example. Have not found a similar feature in Obj-C tho.