Backend Troubleshooting on LOCRIAN_V Blog

The Incompatibility Between PostgreSQL and Java's LocalDateTime

Sat, 25 Oct 2025 12:55:49 +0800

Java’s LocalDateTime and PostgreSQL’s time types “aren’t talking about the same kind of time.”

First, get clear on PostgreSQL’s two time types

TIMESTAMP           → without time zone, just a bare time "2026-06-25 10:00:00"
TIMESTAMPTZ         → with time zone, stored internally as UTC, converted to the session time zone on query

On the Java side

LocalDateTime       → no concept of a time zone, just a bare time
ZonedDateTime       → with time zone
OffsetDateTime      → with an offset (e.g. +08:00)
Instant             → a UTC timestamp

Why the error happens

The PostgreSQL JDBC driver (especially newer versions 42.x+) is very strict about type matching:

Swagger 2 vs. Swagger 3 Annotation Comparison Table

Thu, 25 Sep 2025 09:06:35 +0800

In the Spring Boot ecosystem, the annotations changed a great deal between Swagger 2.0 (typically using the Springfox dependency) and Swagger 3.0 (typically using the Springdoc-openapi dependency, based on the OpenAPI 3 spec).

Below is a complete correspondence table of the common annotations in Swagger 2.0 vs. Swagger 3.0 (OpenAPI 3):

1. Core annotation correspondence table

Description	Swagger 2.0 annotation (io.swagger.annotations)	Swagger 3.0 annotation (io.swagger.v3.oas.annotations)	Notes
Mark a controller class	`@Api(tags = "User API")`	`@Tag(name = "User API")`	3.0 removed the `description` attribute; use `name` uniformly
Mark an API method	`@ApiOperation(value = "Get user")`	`@Operation(summary = "Get user")`	In 3.0 `value` became `summary`
Request/entity class	`@ApiModel(value = "User object")`	`@Schema(description = "User object")`	3.0 greatly simplified this; use `@Schema` uniformly
Entity class property	`@ApiModelProperty(value = "Name")`	`@Schema(description = "Name")`	As above, merged into `@Schema`
Ignore a property	`@ApiModelProperty(hidden = true)`	`@Schema(hidden = true)`
Ignore a whole class/method	`@ApiIgnore`	`@Hidden`	For endpoints or parameters you don’t want exposed in docs

2. Request-parameter annotation correspondence table

For method parameters (URL path parameters, query parameters, etc.), 3.0 introduced a more structured configuration:

SCA 2023.X — Troubleshooting and Fixing the Nacos Bootstrap Config Failure

Thu, 24 Jul 2025 22:40:26 +0800

Issue source: spring-cloud-alibaba#3931
Affected versions: spring-cloud-alibaba 2023.0.1.3+

1. Problem Description

In Spring Cloud Alibaba 2023.X, placing Nacos config (including extension-configs, shared-configs, etc.) in bootstrap.yml / bootstrap.properties causes the config center’s content to fail to load properly, even though the logs show the bootstrap file itself was read.

Moving the same config to application.yml makes everything work again.

2. Root Cause

flowchart TD
    A[bootstrap.yml is read] --> B{SCA version check}
    B -- 2023.0.1.2 and earlier --> C[✅ Nacos config center loads normally]
    B -- 2023.0.1.3 and later --> D[❌ extension-configs / shared-configs fail]
    D --> E[Root cause: SCA 2023.0.1.3 changed the config-load priority mechanism]
    E --> F[Nacos PropertySource registered in the bootstrap phase is overwritten or discarded by later steps]

In short:
SCA 2023.0.1.3 made a backward-incompatible internal change, causing the Nacos extension config in bootstrap.yml to be “dropped” in the loading chain, while config in application.yml takes the new path and is unaffected.