ACEDBers,
Jean Thierry-Mieg <mieg at kaa.crbm.cnrs-mop.fr>:
] It is internally a time_t and arithmetics can be
] preformed on it in particular the query can find the max min average
] off a set of dates, I am not sure if average works well by the way on
] dates.
] The input format is the "%c: unix format described in man ctime
] sois a string of char but it is internally converted to a time_t number
]
] This is part of the soon to be released ace.3-1
John McCarthy <jlmccarthy at lbl.gov>:
] I think this will be very useful.
]
] As I read man ctime, it says that %c is date and time as %x %X, where
] %x is date, using locale's date format; and
] %X is time, using locale's time format
]
] e.g, "Thu, 31 Mar 94 02:05:57 PST"
]
] If the format's are locale-dependent, could this cause problems if we
] are passing data among different locations in .ace files, and one location
] uses different date and time formats from another? If so, perhaps the
] default should be a locale-independent representation.
The internal representation, time_t, _is_ locale independent. It is the
number of seconds since the epoch, which is defined to be Jan. 1, 1970,
00:00, Greenwich Mean Time.
When producing an ASCII string:
ctime(3V)
integer seconds since ====================> ASCII string
the epoch
ctime(3V) takes into account the local timezone. The reverse direction:
(pack a struct tm, then
call) timelocal(3V)
ASCII string ====================> integer seconds since
the epoch
takes as input a timezone (or the local timezone if none is specified)
and produces the (locale-independent) number of seconds since the epoch.
Hence it doesn't matter that the displayed representation of the time
is not locale independent.
Eric De Mund <eademund at lbl.gov>
