On Fri, Sep 28, 2012 at 2:28 AM, Nils Gladitz <glad...@sci-vis.de> wrote:
> Why is TIMESTAMP misleading? > > Per default it currently outputs year, month, day, hour, minute and second. > This includes both a date (a day on a calendar) as well as time (time of > day). > > "Timestamp" I'd define as both date and time bound to an event (here the > call or the (sub-)command). > > "Date" I'd consider inaccurate since it implies that there is no time > resolution. > > "Time" I'd say would be slightly more accurate since it has higher > precision and it matches the naming in C (time_t, tm, strftime ...). > > "DateTime" Is accurate and has precedence (e.g. SQL) but is (IMO) not as > pretty. > > To list them in order of personal preference this would for me give: > Timestamp, DateTime, Time, Date > > Nils > > > > On 09/27/2012 07:41 PM, Eric Noulard wrote: > >> 2012/9/27 David Cole <david.c...@kitware.com>: >> >>> Hmmmm. Good idea. >>> >>> Should we add a new command for this? Or should it be a sub-command of >>> "string(" like RANDOM is? >>> >>> And... while we're at it, I've always thought we should add the >>> ability to get the creation/modified/access times from a file via the >>> CMake file command. If we allow getting the "current" time, we should >>> leverage some of the same transformation-to-string code in the file >>> command to get the various times associated with a file. >>> >>> What do other devs here think: >>> New command or string sub-command for this functionality? >>> >> string sub-command for me, and agreed with Brad as well >> for the "namespace" thing. >> >> agreed with file(...) extension as well. >> >> that said isn't the "TIMESTAMP" misleading? >> shouldn't it be called "DATE" instead? >> >> >> >> > > -- > Nils Gladitz, B.Sc. > DICOM, Konnektivität und Entwicklung > > Scivis wissenschaftliche Bildverarbeitung GmbH > Bertha-von-Suttner-Str. 5 > D-37085 Göttingen > GERMANY > Handelsregister Nr. / Trade Register No. B3100 Göttingen > Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland > > Tel: 0049 (0)551 634181-28 > E-Mail: glad...@scivis.de > Web: www.scivis.de > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/** > opensource/opensource.html<http://www.kitware.com/opensource/opensource.html> > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/**CMake_FAQ<http://www.cmake.org/Wiki/CMake_FAQ> > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developers<http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers> > I agree with Nils here. I like Timestamp or DateTime best since it has resolution down to (at least) the second. Nils, we do not have a formal definition of coding style written out anywhere. To summarize our expectations briefly, though, I'd say this: When modifying existing files, try to blend in with the existing style. When editing C++ source or header files, keep line length under 80 characters per line. When adding a new file, copy the style from another file nearby. With *.cmake files, please use lowercase commands. When defining functions or macros in the CMake language, use "${FileName}_" as a prefix for functions defined in a *.cmake file, where FileName.cmake is the name of the containing file. And ask questions here if there's anything that's unclear. Thanks, David
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers