This might be a simple one but I can't seem to find an easy solution. I need to format a date as a string to be represented in a full form for a locale. Example:
May 28, 2011 (for US locale)
_strftime_l(_T("%#x")) can do a similar thing but it adds a weekday up front, that I don't need.
GetDateFormat and GetTimeFormat (or the Ex versions for Vista and up).
Related
I'm writing Lua (5.3) in a Windows environment; the result will be used in many countries so file handling has to cater for multiple locales (which rules out the lfs and Penlight libraries) and also many date formats (as selected by the user).
I'm accessing files using luacom and Microsoft FileObject, which eliminates problems with file names, but I'm having difficulty with the DateLastModified property, which is returned in text.
I need to compare the DateLastModified for many hundreds of files to determine which is the latest.
One technique I've considered would involve temporarily setting (via the registry) the PC's Short Date format to something predictable that can be simply parsed such as "yyyy-MM-dd" (and resetting it afterwards) but I'm instinctively averse to messing with the user's registry settings, especially those that have ramifications outside my program.
I could copy each file to a temporary file with a name that allows lfs to get the modification data as an integer number of seconds, but that would seriously impact the run-time of what's supposed to be a fairly basic utility.
Is there a solution I've overlooked, or am I going to have to choose the least worst option? Note: I'm quite restricted in the libraries available in the target environment.
Although the default behaviour of Luacom is to return a Date as a text string (based on the current locale), it is possible to modify this behaviour:
3.4.6 DATE type
When converting from COM to Lua, the default behavior is to transform DATE values to strings formatted according to the current locale. The converse is true: LuaCOM converts strings formatted according to the current locale to DATE values. The script can change the conversion from strings to tables by setting the DateFormat field of the luacom table (the LuaCOM namespace) to the string "table". The table will have Day, DayOfWeek, Month, Year, Hour, Minute, Second, and Milliseconds fields. To return the conversion to strings, set the DateFormat field to "string". Be careful with this feature, as it may break compatibility with other scripts.
From Luacom documentation
I need to create a PDF with a date field that displays dates in the format dd.mm.yyyy. This field must be validated and should also accept inputs in other formats.
For example, users should be able to input dates in the form dd.mm.yy, which will then be expanded to dd.mm.20yy (MS Office apps like Excel do this).
Alternatively, selecting multiple valid formats would be an acceptable solution.
What currently happens:
If the date format of the field is set to dd.mm.yyyy, dd.mm.yy is rejected.
If the date format of the field is set to dd.mm.yy, dd.mm.yyyy is accepted (but formatted to dd.mm.yy).
The last behaviour is almost what i need, just with the wrong format.
Is there a way to do this without custom Javascript? If not, is there a way to still use the built-in formatting or do i have to rewrite everything in JS?
Unfortunately this is not achievable with Acrobat's built-in formatting.
One thing to add to your second bullet point: it trims the date down to .yy when you exit the field, but it still retains all four digits. When you click into the field, it will revert back to being .yyyy. That may or may not matter depending on how you're using it.
Regarding a custom validation, a quick Google search will yield an abundance of Javascript date validation scripts. Something like this could probably be quickly repurposed for your application.
I have a page that tells the user to input a time in the format hh:mm:ss. This is obviously fine for English speaking audiences, but is this an acceptable international notation?
If not, could you give me some examples of how other countries display this kind of information to the user.
In terms of time, it is usually either in format hh:mm:ss or h:mm:ss, that is you either do zero-padding or no zero padding for single digits hours.
Another thing is, the format - distinction between 12 hours and 24 hours, that also varies from Locale to Locale.
Lastly, you should take into account local user's time zone - it is natural to enter the time in relation to current time zone.
How would you go about these options? Basically, it depends on what your UI look like. If you have just one text box where user can enter free-form text, you should actually parse the text according to valid Locale format. In that case you can give an example of the format, by formatting current day, so the label would say something like "Enter the time (for example: 16:36:11):".
Other approach is to have two (hour/minute) or more text fields (seconds) separated by time separator (":") and possibly conditional AM/PM radio button group (or drop down). In that case it would be a bit harder, because to do that correctly, you should actually analyze the localized pattern (on what is and what is not supported) and dynamically create UI elements (I don't want to see AM/PM stuff as I am using 24 hours time naturally) as well as validation rules...
I know dates are different between different country, but time is pretty standard. you won't have problem with French, spanish, german, UK... i don't know for asian country tho...
Are there any other languages that default to anything other than ddmmyyyy (other than the US)?
I'm working on an international project and wondering if there are any other languages that use the mmddyyyy date format. I have a limited knowledge of many languages but so far it seems most use ddmmyyyy instead.
There are even more variations. Check Wikipedia:
List of the world locations by date format in use
This may be of interest: http://en.wikipedia.org/wiki/Calendar_date
I am saving all my notes in a log file. Each line is a note, suffixed by tags, and prefixed by a date and time marker, which currently looks like this: [12.20.09:22.22] ([date:time].
I am planning to have this a long-living format. Notes will be logged willy-nilly with this format 20-30 times a day for years to come. I foresee numerous kinds of parsing for analytics, filtering, searching ...
I am worried about the [ ]s though. Could they possibly trip some parsing code (someone else's if not mine)? What would be the most non-confrontational marker?
If you end up going with your own format, can I recommend ISO 8601 for your date and time format.
In summary, the basic format is:
yyyy-mm-dd hh:mm:ss
You can extend this with timezone and microsecond info if you wish. Timezone is recommended or assume UTC.
With the date/time in this format there's no confusion over which is the month and the day. And it has the bonus of sorting using a basic string sort.
I'd consider using either XML or JSON as the format for the file.
In particular your date/time marker is ambiguous. Is it mm/dd/yy or dd/mm/yy? Or even yy/mm/dd? And in what timezone is the date and time?
Both XML and JSON define a way to have dates that are culture and timezone independent, and (best of all) there's masses of tooling available for both formats.
XML datetime format is defined here: for example, 2000-01-12T12:13:14Z.
JSON datetime format is defined as the number of seconds since Jan 1, 1970, so it's a bit uglier: { currentDate: "#1163531522089#" }
If you want everything to last in a long-lived format, then the metadata needs to be as explicit as possible. If it's intended to be long-lived, then many others will need to read it, as easily as possible.
I agree with Jeremy McGee: XML is an excellent choice. Even if no other data lives, then having it be in the format:
<note>
<datetime>
<year>
2009
</year>
<month>
12
</month>
. . .
</datetime>
<message>
Foo bar baz quox
</message>
<note>
cannot be misunderstood.
This depends on your data. However, if you escape them with a special character of some sort, (i.e. \]) and code accordingly to look at the previous character when finding a "[" or "]", you should have no problem.
Also, if you're open to a new format, I'm a fan of JSON as it's light weight and very useful.
Using '[]' as the markers would be ok provided that you allow the DSL the ability to escape the characters. This is typical of operations on text which need parsing.
As an example check out the typical regular expression syntax which enables '/' as the seperator, whilst letting the user specify an escape character such as '\'. You may get some more ideas from the likes of such Unix tools as; awk, sed and grep
I would tend to think a standardized format is the way to go, with JSON being my personal choice because of it's simplicity. Not only does that help to avoid parsing issues since others have already though about it, you are also given a lot more tools to work with over the life of the project.