• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Date/Time Handling Mistakes

 
Ranch Hand
Posts: 70
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Congrats Tomasz Lelek and Jon Skeet on your book: Software Mistakes and Tradeoffs

A mistake I have seen in multiple large projects has been related to consistent Date/Time Handling.

Users and Coders often use different Date/Time formats. (mm/dd/yyyy vs dd/mm/yyyy vs. yyyy/mm/dd etc., etc.) (Time format: 12 hour vs. 24 hour, seconds, etc.)

This problem becomes even more complex when an application shares data with other programs that may use different Date/Time formats and data needs to be used as an input/output for other applications.

What steps/procedures/documentation do you recommend to avoid or minimize mistakes related to inconsistent date/time handling?
 
Marshal
Posts: 80214
423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are those date/time formats? I would have thought they are date/time display formats, or parsing formats. That sounds a bit like an internationalisation problem. Maybe you can separate parsing and display from processing or storing of dates and times. Maybe make your methods and constructors take LocalDateTime or other types from the date time framework, and let other code do the parsing and displaying.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not suggesting that this is an approach which is universally appropriate, but I have found that software can be a lot easier to reason about  if dates and datetimes are stored and processed as seconds-from-the-epoch and only converted to timezones and human-readable formats at the edge of the system, such as for display on a screen.

This does, of course, raise the issue of when was the "epoch". In most systems it is usually 01-01-1970, but I have seen others.
 
Geoff McKay
Ranch Hand
Posts: 70
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Are those date/time formats? I would have thought they are date/time display formats, or parsing formats. That sounds a bit like an internationalisation problem...



Thanks Campbell. Yes these are display formats to demonstrate a formatting problem we encountered on a project. The program would read and process a Text file (or XML file) as an import of remote/branch transactions for data processing. This input file stored the dates as strings in a comma delimited file. These files were generated on different computers, and the date format of the resultant strings would vary (MM/DD/YYYY vs. DD/MM/YYYY etc.) based on the System Locale settings of the individual workstations used to generate the transaction file(s) for processing. The issue was detected during testing, but it required the addition of a "Locale Settings" check via the program before exporting files. But, this is an example of a real world date/time formatting issue we encountered that needed to be addressed.
 
Geoff McKay
Ranch Hand
Posts: 70
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Frank Carver wrote:... I have found that software can be a lot easier to reason about  if dates and datetimes are stored and processed as seconds-from-the-epoch and only converted to timezones and human-readable formats...



Thanks Frank,
Agreed. Using date/time processing as an "offset" from a standardized date is a workable solution. I have seen some systems use Julian date solutions.
 
Campbell Ritchie
Marshal
Posts: 80214
423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Different formats in different XML/comma‑separated files? That sounds like a nightmare, far worse than I thought at first.
 
Good night. Drive safely. Here's a tiny ad for the road:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic