🚀 go-pugleaf

ACEDBers,

Jean Thierry-Mieg <mieg@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@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@lbl.gov>