Skip to main content
Code Review

Return to Answer

edited body
Source Link
Joop Eggen
Joop Eggen
  • 4.7k
  • 15
  • 19

Human dates are highly convoluted.

  • With daylight saving time (DST) the notation of one specific hour disappears (is illegal), and a half year later there are two hours with the "same" notation.
  • Twenty four hours later may be one a different hour. One day later might not be 24 hours.

My conclusion is that internally one should opt for UTC internally, in database and logs, and human zoned date time on the front-end.

Your Do-It-YeurselfYourself Date Time Library

Having a simple, reduced library is very alluring, promising faster development, shorter code. However I would refrain from it.

You have to deal with already well established things.

  • Sorting on time parts probably needs YYYYMMDD (with %02d) and 24 hour time.
  • Time zones. International foreign communication.

It would be better to create a documented collection of code snippets "How to Work with Time" in unit tests for many solutions - based on an existing library.

The work (functionality) is the same. The effort now a bit higher. The tool set will hold longer - new developers might already be acquainted with the library, and become acquainted with a more ubiquitous library.

That said

You might do a wrapping library in the style of inline functions, but mainly creating code snippets for all kind of needed functionality.

  • Using dates in the database (UTC?)
  • Representing dates, time zones
  • Time calculation
  • Sorting
  • Business Knowledge, working days

This means you search for working solutions in an existing environment, instead of inventing new conventions. "Refrain from writing your own classes."

Human dates are highly convoluted.

  • With daylight saving time (DST) the notation of one specific hour disappears (is illegal), and a half year later there are two hours with the "same" notation.
  • Twenty four hours later may be one a different hour. One day later might not be 24 hours.

My conclusion is that internally one should opt for UTC internally, in database and logs, and human zoned date time on the front-end.

Your Do-It-Yeurself Date Time Library

Having a simple, reduced library is very alluring, promising faster development, shorter code. However I would refrain from it.

You have to deal with already well established things.

  • Sorting on time parts probably needs YYYYMMDD (with %02d) and 24 hour time.
  • Time zones. International foreign communication.

It would be better to create a documented collection of code snippets "How to Work with Time" in unit tests for many solutions - based on an existing library.

The work (functionality) is the same. The effort now a bit higher. The tool set will hold longer - new developers might already be acquainted with the library, and become acquainted with a more ubiquitous library.

That said

You might do a wrapping library in the style of inline functions, but mainly creating code snippets for all kind of needed functionality.

  • Using dates in the database (UTC?)
  • Representing dates, time zones
  • Time calculation
  • Sorting
  • Business Knowledge, working days

This means you search for working solutions in an existing environment, instead of inventing new conventions. "Refrain from writing your own classes."

Human dates are highly convoluted.

  • With daylight saving time (DST) the notation of one specific hour disappears (is illegal), and a half year later there are two hours with the "same" notation.
  • Twenty four hours later may be one a different hour. One day later might not be 24 hours.

My conclusion is that internally one should opt for UTC internally, in database and logs, and human zoned date time on the front-end.

Your Do-It-Yourself Date Time Library

Having a simple, reduced library is very alluring, promising faster development, shorter code. However I would refrain from it.

You have to deal with already well established things.

  • Sorting on time parts probably needs YYYYMMDD (with %02d) and 24 hour time.
  • Time zones. International foreign communication.

It would be better to create a documented collection of code snippets "How to Work with Time" in unit tests for many solutions - based on an existing library.

The work (functionality) is the same. The effort now a bit higher. The tool set will hold longer - new developers might already be acquainted with the library, and become acquainted with a more ubiquitous library.

That said

You might do a wrapping library in the style of inline functions, but mainly creating code snippets for all kind of needed functionality.

  • Using dates in the database (UTC?)
  • Representing dates, time zones
  • Time calculation
  • Sorting
  • Business Knowledge, working days

This means you search for working solutions in an existing environment, instead of inventing new conventions. "Refrain from writing your own classes."

deleted 1 character in body
Source Link
Joop Eggen
Joop Eggen
  • 4.7k
  • 15
  • 19

Human dates are highly convoluted.

  • With daylight saving time (DST) the notation of one specific hour disappears (is illegal), and a half year later there are two hours with the "same" notation.
  • Twenty four hours later may be one a different hour. One day later might not be 24 hours.

My conclusion is that internally one should opt for UTC internally, in database and logs, and human zoned date time on the front-end.

Your Do-It-Yeurself Date Time Library

Having a simple, reduced library is very alluring, promising faster development, shorter code. However I would refrain from it.

You have to deal with already well established things.

  • Sorting on time parts probably needs YYYYMMDD (with %02d) and 24 hour time.
  • Time zones. International foreign communication.

It would be better to create a documented collection of code snippets "How to Work with Time" in unit tests for many solutions - based on an existing library.

The work (functionality) is the same. The effort now a bit higher. The tool set will hold longer - new developers might already be acquainted with the library, and become acquainted with a more ubiquitous library.

That said

You might do a wrapping library in the style of inline functions, but mainly creating code snippets for all kind of needed functionality.

  • Using dates in the database (UTC?)
  • Representing dates, time zones
  • Time calculation
  • Sorting
  • Business KnopwledgeKnowledge, working days

This means you search for working solutions in an existing environment, instead of inventing new conventions. "Refrain from writing your own classes."

Human dates are highly convoluted.

  • With daylight saving time (DST) the notation of one specific hour disappears (is illegal), and a half year later there are two hours with the "same" notation.
  • Twenty four hours later may be one a different hour. One day later might not be 24 hours.

My conclusion is that internally one should opt for UTC internally, in database and logs, and human zoned date time on the front-end.

Your Do-It-Yeurself Date Time Library

Having a simple, reduced library is very alluring, promising faster development, shorter code. However I would refrain from it.

You have to deal with already well established things.

  • Sorting on time parts probably needs YYYYMMDD (with %02d) and 24 hour time.
  • Time zones. International foreign communication.

It would be better to create a documented collection of code snippets "How to Work with Time" in unit tests for many solutions - based on an existing library.

The work (functionality) is the same. The effort now a bit higher. The tool set will hold longer - new developers might already be acquainted with the library, and become acquainted with a more ubiquitous library.

That said

You might do a wrapping library in the style of inline functions, but mainly creating code snippets for all kind of needed functionality.

  • Using dates in the database (UTC?)
  • Representing dates, time zones
  • Time calculation
  • Sorting
  • Business Knopwledge, working days

This means you search for working solutions in an existing environment, instead of inventing new conventions. "Refrain from writing your own classes."

Human dates are highly convoluted.

  • With daylight saving time (DST) the notation of one specific hour disappears (is illegal), and a half year later there are two hours with the "same" notation.
  • Twenty four hours later may be one a different hour. One day later might not be 24 hours.

My conclusion is that internally one should opt for UTC internally, in database and logs, and human zoned date time on the front-end.

Your Do-It-Yeurself Date Time Library

Having a simple, reduced library is very alluring, promising faster development, shorter code. However I would refrain from it.

You have to deal with already well established things.

  • Sorting on time parts probably needs YYYYMMDD (with %02d) and 24 hour time.
  • Time zones. International foreign communication.

It would be better to create a documented collection of code snippets "How to Work with Time" in unit tests for many solutions - based on an existing library.

The work (functionality) is the same. The effort now a bit higher. The tool set will hold longer - new developers might already be acquainted with the library, and become acquainted with a more ubiquitous library.

That said

You might do a wrapping library in the style of inline functions, but mainly creating code snippets for all kind of needed functionality.

  • Using dates in the database (UTC?)
  • Representing dates, time zones
  • Time calculation
  • Sorting
  • Business Knowledge, working days

This means you search for working solutions in an existing environment, instead of inventing new conventions. "Refrain from writing your own classes."

Source Link
Joop Eggen
Joop Eggen
  • 4.7k
  • 15
  • 19

Human dates are highly convoluted.

  • With daylight saving time (DST) the notation of one specific hour disappears (is illegal), and a half year later there are two hours with the "same" notation.
  • Twenty four hours later may be one a different hour. One day later might not be 24 hours.

My conclusion is that internally one should opt for UTC internally, in database and logs, and human zoned date time on the front-end.

Your Do-It-Yeurself Date Time Library

Having a simple, reduced library is very alluring, promising faster development, shorter code. However I would refrain from it.

You have to deal with already well established things.

  • Sorting on time parts probably needs YYYYMMDD (with %02d) and 24 hour time.
  • Time zones. International foreign communication.

It would be better to create a documented collection of code snippets "How to Work with Time" in unit tests for many solutions - based on an existing library.

The work (functionality) is the same. The effort now a bit higher. The tool set will hold longer - new developers might already be acquainted with the library, and become acquainted with a more ubiquitous library.

That said

You might do a wrapping library in the style of inline functions, but mainly creating code snippets for all kind of needed functionality.

  • Using dates in the database (UTC?)
  • Representing dates, time zones
  • Time calculation
  • Sorting
  • Business Knopwledge, working days

This means you search for working solutions in an existing environment, instead of inventing new conventions. "Refrain from writing your own classes."