Apply the configured timezone to PHP and both DB connections, wrap unwrapped ajax payloads so delete buttons reach their engines, normalise and validate invoice due dates, reject stock quantities below the stored 4dp scale, and list stock movements across all warehouses.
41 lines
1.6 KiB
PHP
41 lines
1.6 KiB
PHP
<?php
|
|
// Applies the configured application timezone to PHP, and exposes the matching
|
|
// UTC offset so the database session can be pinned to the same zone.
|
|
//
|
|
// config.php has always defined $time_zone ("Asia/Bangkok"), but nothing ever
|
|
// called date_default_timezone_set() with it. PHP therefore ran on its ini
|
|
// default (UTC on this stack) while MySQL NOW() ran on the database server's
|
|
// zone (Bangkok). Every timestamp written from PHP — stock movement `date`
|
|
// above all — was stored 7 hours behind the real wall clock, so a stock-in
|
|
// created at 14:02 was listed as 07:02.
|
|
//
|
|
// Loaded from dbconn.php (covers every API engine, which is where writes
|
|
// happen) and from include_header.php (covers the rendered pages).
|
|
|
|
if (!defined('APP_TIMEZONE')) {
|
|
|
|
$app_tz = $GLOBALS['time_zone'] ?? 'Asia/Bangkok';
|
|
|
|
// An unknown identifier would leave PHP on UTC and silently reintroduce the
|
|
// skew, so fall back to the documented project zone instead.
|
|
try {
|
|
$tz = new DateTimeZone($app_tz);
|
|
} catch (Exception $e) {
|
|
$app_tz = 'Asia/Bangkok';
|
|
$tz = new DateTimeZone($app_tz);
|
|
}
|
|
|
|
date_default_timezone_set($app_tz);
|
|
define('APP_TIMEZONE', $app_tz);
|
|
|
|
// "+07:00" — the form MySQL accepts without its named-timezone tables
|
|
// having been loaded, which is the usual case on a stock install.
|
|
$offset_seconds = $tz->getOffset(new DateTime('now', $tz));
|
|
define('APP_TIMEZONE_OFFSET', sprintf(
|
|
'%s%02d:%02d',
|
|
$offset_seconds < 0 ? '-' : '+',
|
|
intdiv(abs($offset_seconds), 3600),
|
|
intdiv(abs($offset_seconds) % 3600, 60)
|
|
));
|
|
}
|