2020-10 以jdk8的Date/Time API為例探討時區(qū)相關(guān)的概念

本文主要探討和時區(qū)相關(guān)的概念罚屋,并以jdk8的Date/Time API為例,明確我們在處理和時區(qū)相關(guān)的問題時榜聂,應當如何正確理解和使用已有的API,其他的編程語言和工具涝桅,應當也是可以觸類旁通的拜姿。

提出問題

時間是我們最熟悉不過的概念,日常工作中也經(jīng)常要處理和時間相關(guān)的業(yè)務需求冯遂,比如用戶創(chuàng)建時間蕊肥、最后更新時間等等,常用的編程語言一般都提供了成熟的工具類庫和API蛤肌,來協(xié)助我們實現(xiàn)時間的生成壁却、轉(zhuǎn)化、格式化顯示等需求裸准,因此大多數(shù)場景下時間的處理并不是一個復雜的問題展东。

但是時區(qū)正是其中比較復雜和容易出錯的一類問題,這個復雜性主要來源于兩個方面:一是和時區(qū)相關(guān)的概念紛繁復雜炒俱,常見的像如UTC時間盐肃、DST時間、GMT权悟、CST砸王、本地時間等等;另外一個原因是我們常見的應用不太會垮時區(qū)部署峦阁,因此也不太會關(guān)注時區(qū)的處理谦铃,一般都是用系統(tǒng)默認時區(qū)即可,因此一旦出現(xiàn)和時區(qū)相關(guān)的問題榔昔,往往感覺模棱兩可驹闰。

雖然我們直接使用時區(qū)的場景不多,但是編寫代碼時常用的工具類庫撒会、數(shù)據(jù)庫等系統(tǒng)嘹朗,都隱含了對時區(qū)的處理,導致我們不經(jīng)意之間一直在使用時區(qū)诵肛,如果不能對這些時區(qū)概念有正確的理解屹培,就很容易觸發(fā)一些隱含的問題。

本文將從一個最簡單的時區(qū)轉(zhuǎn)化問題出發(fā)曾掂,闡明處理時區(qū)問題時所涉及的概念惫谤。

  • 問題:歐冠決賽在北京時間2020年8月24日 03:00開始壁顶,那么比賽開始時珠洗,倫敦的當?shù)貢r間是什么時候?

從日常經(jīng)驗來看若专,北京位于東八區(qū)许蓖,而倫敦位于零時區(qū),北京時間應該比倫敦時間快8個小時,那真正的結(jié)果是這樣嗎膊爪?我們在代碼中應當如何做這個時區(qū)的轉(zhuǎn)化呢自阱?

概念解讀

分析時區(qū)問題時有一個最基本的準則,那就是:

  • 絕對時間 = 本地時間 & 時區(qū)偏移量 (AbsoluteTime = LocalDateTime & Offset)

具體含義是米酬,本地時間和時區(qū)偏移量的信息組合可以描述一個絕對時間沛豌。

絕對時間、本地時間赃额、時區(qū)偏移量的概念將在下面一一解讀加派。

1.絕對時間(AbsoluteTime)

絕對時間可以理解為一個放之四海而皆準的時間,舉個例子跳芳,UTC時間就是一個絕對時間芍锦,當我們記錄一個時間為1970-01-01T00:00:00Z(UTC描述時間的標準格式)時,這個時間的定義是沒有任何歧義的飞盆,它指向絕對時間線上的一個確定的時刻娄琉;從另一個角度說,在同一時刻吓歇,地球上的任何角落同時發(fā)生的事情孽水,他們的UTC時間也一定是相同的,這就是絕對時間照瘾。

另外一個常見的絕對時間是Unix時間戳匈棘,它也指向絕對時間線上的一個確定的時刻,不受所在地的影響析命。

正是因為絕對時間對時間的描述不存在任何歧義主卫,因此將時間轉(zhuǎn)化為絕對時間來處理是非常可靠的鹃愤,這也是我們在處理時區(qū)問題時的不二法門簇搅。

2.本地時間(LocalDateTime)

先舉個本地時間的例子,上面的描述中“歐冠決賽在北京時間2020年8月24日 03:00開始“软吐,其中的“北京時間2020年8月24日 03:00”是我們這里所說的本地時間嗎瘩将?答案是否定的,這里的本地時間是指“2020年8月24日 03:00”凹耙,并不包含“北京時間”這個和時區(qū)相關(guān)的描述姿现。本地時間僅僅是指的關(guān)于年月日、時分秒等信息的一個描述肖抱,并不包含所在的時區(qū)备典,這是一個非常容易混淆的地方。再次明確一遍意述,我們確實是在某一個時區(qū)下得到了“本地時間”提佣,但是我們得到的“本地時間”本身是不包含時區(qū)的吮蛹,這是理解時區(qū)問題時非常關(guān)鍵的一點。

為了進一步區(qū)分絕對時間和本地時間的概念拌屏,我們對常見的時間類型做些歸類潮针。

通用概念 java
絕對時間 UTC時間,Unix時間戳倚喂,1970-01-01T00:00:00Z Instant ZonedDateTime OffsetDateTime
本地時間 2020年8月24日 03:00 LocalDateTime

3.時區(qū)偏移量(Offset)

全球分為24個時區(qū)每篷,每個時區(qū)和零時區(qū)相差了數(shù)個小時,也就是這里所說的時區(qū)偏移量Offset端圈,比如東八區(qū)和零時區(qū)有+08:00的偏移量雳攘。還是回到上面的例子,“北京時間2020年8月24日 03:00”本質(zhì)上是一個絕對時間枫笛,表示成UTC時間是2020-08-24T03:00:00+08:00吨灭,其中的2020-08-24T03:00:00是本地時間,而+08:00表示的是時區(qū)偏移量刑巧。UTC的表示方法正印證了上面所闡述的準則:絕對時間=本地時間&時區(qū)偏移量喧兄。

時區(qū)偏移量的概念比較簡單,但是計算卻比較復雜啊楚,其計算方式是:

  • 時區(qū)偏移量 = 地區(qū) & 規(guī)則 (Offset = Zone & Rules)

這里的規(guī)則(Rules)可能是一個變化的值吠冤,如果我們單純地認為中國的時區(qū)偏移量是8個小時,就出錯了恭理,事實是拯辙,中國采用的不一定總是東八區(qū)時間,也可能是東九區(qū)時間颜价,出現(xiàn)這個情況因為夏令時的存在(夏令時即DST時間涯保,1992年之后中國已經(jīng)沒有再實行過夏令時了,所以大家對這個概念并不熟悉周伦,這是一個比較有意思的時間規(guī)定夕春,感興趣的同學可以參看文末附錄),當實行夏令時的時候专挪,中國標準時間的時區(qū)偏移量就是+09:00及志。因此,一個地區(qū)的時區(qū)偏移量是多少寨腔,是由當?shù)氐恼邲Q定的速侈,可能會隨著季節(jié)而發(fā)生變化,這就是上面所說的“規(guī)則”(Rules)迫卢。

好在倚搬,這些復雜的規(guī)則一般都被我們的API支持了,但是我們必須意識到的一點是靖避,“Asia/Shanghai”和“+08:00”是不同的時區(qū)描述潭枣,“Asia/Shanghai”只是描述了地區(qū),而“+08:00”描述了準確的時區(qū)偏移量幻捏,不能將它們看作等價盆犁,比如在實行夏令時的時候,這兩種描述得到的本地時間就是不同的篡九。

實際上谐岁,時區(qū)還有更多復雜的規(guī)定,我們不再去深究榛臼,目前已知的這些足夠我們處理日常的需求了伊佃。

Java jdk8的Date/Time API介紹

jdk8之前的Date/Time API被吐槽已久,如果你不幸是從jdk8之前的Date Calendar類開始了解時間類的處理沛善,很可能會一頭霧水航揉,其用法和缺點我們這里不再探討,強烈推薦直接使用jdk8提供了新的Date/Time API金刁。

1.Date/Time API常用類的介紹

jdk8 Date/Time API中常用的類完全符合我們上述提到的概念:

  • 絕對時間:java.time.Instant, java.time.OffsetDateTime, java.time.ZonedDateTime

  • 本地時間:java.time.LocalDateTime

  • 時區(qū)偏移量:java.time.ZoneOffset

1.1 java類庫中的絕對時間

Instant本質(zhì)上是一個Unix時間戳帅涂,Unix時間戳是可以表示絕對時間的,只不過Instant內(nèi)部用了兩個long的對象分別表示秒和納秒尤蛮,從而將精度支持到了納秒級別媳友。

OffsetDateTime是一個包含了時區(qū)(offset)信息的時間類型,內(nèi)部保存了LocalDateTime(本地時間)和offset产捞,由于本地時間和時區(qū)信息都是完整的醇锚,所以OffsetDateTime是一個絕對時間。

ZonedDateTime是一個包含了地區(qū)(zone)信息的時間類型坯临,內(nèi)部保存了LocalDateTime(本地時間)和zone焊唬,由上述兩個值可以計算出時區(qū)(offset),因此也是一個絕對時間看靠。

這里有兩個問題可以探討:

  • 問題一:這三個類都是絕對時間求晶,那么他們是否可以互相轉(zhuǎn)化呢?

  • 問題二:鑒于ZonedDateTime和OffsetDateTime定義是很接近的衷笋,那么使用時該如何選擇呢芳杏?

問題一我們在這里直接回答:答案是只能進行有限的轉(zhuǎn)化,因為三者所包含的信息量是不同的辟宗,如圖爵赵。

image-20201227203413024

從外圍向內(nèi)部的轉(zhuǎn)化是支持的,而從內(nèi)部向外圍的轉(zhuǎn)化必需要補充一些額外的信息(當然這些信息可能是隱含補入的泊脐,如本機所在的時區(qū))空幻;否則只能進行一些特殊的轉(zhuǎn)化,比如將OffsetDateTime直接轉(zhuǎn)成ZonedDateTime的API文檔說明了這一點:This creates the simplest possible ZonedDateTime using the offset as the zone ID.

問題二我們在后面單獨討論容客。

1.2 java類庫中的本地時間

java中對本地時間的描述非常簡單明確秕铛,LocalDateTime類约郁,內(nèi)部包含了LocalDate和LocalTime兩個成員變量,其中LocalDate表示年月日的日期組合但两,而LocalTime表示時分秒納秒的時間組合鬓梅,本質(zhì)上,LocalDateTime只是一個關(guān)于日期和時間的描述谨湘,沒有任何時區(qū)信息绽快,符合我們對本地時間的定義。

當我們描述的只是一個關(guān)于日期或時間的組合紧阔,而不是一個絕對時間的時候坊罢,直接使用本地時間即可,比如記錄一個人的生日擅耽。

1.3 java類庫中的時區(qū)偏移量

ZoneOffset對應了一個確定的時區(qū)偏移量活孩。至于上面提到的

  • 時區(qū)偏移量 = 地區(qū) & 規(guī)則(Offset = Zone & Rules)

其中地區(qū)(Zone)在java中對應著ZoneRegion類,Rules對應ZoneRules類乖仇。同時诱鞠,為了簡化用戶的使用,Java對此做了進一步抽象这敬,設計了ZoneId類用來統(tǒng)籌ZoneOffset和ZoneRegion航夺,通過ZoneId.of("Asia/Shanghai")可以直接生成ZoneRegion,而ZoneId.of("+8")可以生成ZoneOffset崔涂。

其他使用具體API的最佳實踐阳掐,java提供的官方文檔十分明確,且網(wǎng)絡上隨處可查冷蚂,本文不再贅述缭保,相信明確了上述概念之后,再見到這些繁多的API時已經(jīng)能做到心中有數(shù)蝙茶。

2.使用ZonedDateTime還是OffsetDateTime艺骂?

這個問題OffsetDateTime的官方文檔中的解答是

It is intended that {@code ZonedDateTime} or {@code Instant} is used to model data in simpler applications. 
This class(OffsetDateTime) may be used when modeling date-time concepts in more detail, or when communicating to a database or in a network protocol.

具體來看,其中modeling date-time concepts in more detail應當是針對Instant來說的隆夯,OffsetDateTime比Instant信息更豐富(多了時區(qū)信息)钳恕,而communicating to a database or in a network protocol是針對ZonedDateTime來說的,也就是當我們使用數(shù)據(jù)庫以及網(wǎng)絡通信時要使用OffsetDateTime蹄衷,那么原因是什么呢忧额?

因為ZonedDateTime存儲的是地區(qū)(Zone)信息,再通過Rules計算出具體的offset愧口,而問題就在于睦番,Rules是一個政策性的規(guī)則,是不穩(wěn)定的,存在不同的版本托嚣,不同客戶端使用的Rules也可能是不同的巩检,尤其是當我們處理一個未來時間的時候這個問題更加突出,畢竟未來的政策又有誰能預測呢示启?這就導致我們發(fā)送的時間和其他應用解讀到的時間可能會產(chǎn)生差異兢哭,我們保存在數(shù)據(jù)庫中的時間,當未來讀取出來時也可能做出不同的解讀丑搔,所以這種這種情況下,推薦使用OffsetDateTime提揍,因為直接傳遞和保存確定的offset是不會產(chǎn)生歧義的啤月。

那么ZonedDateTime在什么情況下使用呢?當我們必須要使用夏令時或其他地區(qū)性規(guī)則的時候劳跃,應當轉(zhuǎn)化為ZonedDateTime來使用谎仲。

問題分析和解決

那么我們回到最開始的問題:

  • 問題:歐冠決賽在北京時間2020年8月24日 03:00開始,那么比賽開始時刨仑,倫敦的當?shù)貢r間是什么時候郑诺?

在明確了上述概念的基礎(chǔ)上,我們可以對問題做進一步分析杉武,因為比賽開始的絕對時間是相同的辙诞,所以有:

歐冠決賽開始的絕對時間 = 北京的本地時間 & 北京的時區(qū)偏移量 = 倫敦的本地時間 & 倫敦的時區(qū)偏移量

因此只要確定北京和倫敦的時區(qū)偏移量,就可以求得倫敦的本地時間了轻抱。分析到這里飞涂,我們已經(jīng)可以通過Java提供的API來解決上述問題了,Java工具類內(nèi)部會進行時區(qū)偏移量的計算祈搜,不需要我們親自處理较店。

1.Java jdk8的Date/Time API解決時區(qū)轉(zhuǎn)化問題

// Step#1:北京地區(qū)
// 地區(qū):
ZoneId zoneOfBeijing = ZoneId.of("Asia/Shanghai");
// 本地時間:2020-08-24 03:00
LocalDateTime localDateTimeOfBeijing = LocalDateTime.of(2020, 8, 24, 3, 0);
// 絕對時間:ZonedDateTime表示
ZonedDateTime zonedDateTimeOfBeijing = ZonedDateTime.of(localDateTimeOfBeijing, zoneOfBeijing);

// Step#2:絕對時間轉(zhuǎn)化成Instant類型(時間戳類型)
Instant absoluteInstant = zonedDateTimeOfBeijing.toInstant();

// Step#3:倫敦地區(qū)
// 地區(qū):
ZoneId zoneOfLondon = ZoneId.of("Europe/London");
// 絕對時間:將Instant絕對時間轉(zhuǎn)化成倫敦地區(qū)的ZonedDateTime
ZonedDateTime zonedDateTimeOfLondon = ZonedDateTime.ofInstant(absoluteInstant, zoneOfLondon);
// 本地時間:
LocalDateTime localDateTimeOfLondon = zonedDateTimeOfLondon.toLocalDateTime();

System.out.println("北京本地時間:" + localDateTimeOfBeijing);
System.out.println("北京時區(qū)偏移量:" + zonedDateTimeOfBeijing.getOffset());
System.out.println("倫敦本地時間:" + localDateTimeOfLondon);
System.out.println("倫敦時區(qū)偏移量:" + zonedDateTimeOfLondon.getOffset());

/*
北京本地時間:2020-08-24T03:00
北京時區(qū)偏移量:+08:00
倫敦本地時間:2020-08-23T20:00
倫敦時區(qū)偏移量:+01:00
 */

最終得出的結(jié)果,倫敦的本地時間是2020年8月23日 20:00容燕,北京時間比倫敦時間快了7個小時梁呈,這是因為倫敦當時正在實行夏令時,時區(qū)偏移量是+01:00蘸秘。

2.普通的計算方法解決時區(qū)轉(zhuǎn)化問題

如果拋開API官卡,用普通的算數(shù)方法,我們需要進一步明確上述關(guān)系中的&該如何具體化醋虏,直接給出一種方法味抖,我們利用零時區(qū)時間表示的絕對時間來做一個過渡,已知滿足:

  • 零時區(qū)的時間(絕對時間) = 本地時間 - 本地時區(qū)偏移量

可以得到:

北京的本地時間 - 北京的時區(qū)偏移量 = 倫敦的本地時間 - 倫敦的時區(qū)偏移量

即:

倫敦的本地時間 = 北京的本地時間 - (北京的時區(qū)偏移量 - 倫敦的時區(qū)偏移量)

對于時區(qū)偏移量我們直接給出結(jié)論:北京時間2020年8月24日 03:00灰粮,北京的時區(qū)偏移量為+08:00仔涩,而倫敦的時區(qū)偏移量為+01:00(倫敦當時正在實行夏令時)。

因此:

倫敦的本地時間 = 2020年8月24日 03:00 - (+08:00 - +01:00) = 2020年8月23日 20:00

結(jié)論

本文看似是上繞了一個很大的圈子粘舟,解決了一個非常簡單的時區(qū)轉(zhuǎn)化問題熔脂,過程中唯一要注意的坑不過是一個夏令時而已佩研,是但在分析這個問題的過程中,把相關(guān)的概念做了詳細的介紹霞揉,我們也看到了jdk8 Date/Time的API設計在概念上是非常清晰的旬薯,理解這些概念也便于我們正確使用API,避免做一些想當然的轉(zhuǎn)化适秩。

在實際應用中绊序,和時區(qū)相關(guān)的還有一些更重要的問題,比如在數(shù)據(jù)庫中如何保存時間秽荞,以及可能存在哪些隱含的問題等骤公,這些問題的分析也要建立在充分理解上述概念的基礎(chǔ)上,篇幅所限扬跋,將在后面的文章中做進一步探討阶捆。

隨著人認知的不斷加深、測量方法的不斷提升钦听,時間的表示規(guī)范也在不斷演化洒试,也引入了眾多的和時間相關(guān)的標準,但是不管怎么樣朴上,這些標準的目標都是為了規(guī)范時間的表示垒棋,使我們從類似于2020-02-02 20:20:20Z這樣的描述下,能定位到一個公認的痪宰、確定的時刻捕犬。下面就主要介紹一下當前使用的主要時間標準,主要介紹的概念是UTC酵镜、GMT碉碉、DST、CST淮韭,其他的僅做了解即可垢粮。

當前,使用的最廣泛的世界時間標準是世界協(xié)調(diào)時(Coordinated Universal Time)靠粪,簡稱UTC蜡吧,這個簡稱是由英文縮寫(CUT)和法文縮寫(TUC)妥協(xié)而來。

UTC有個比較特別的地方占键,存在一個閏秒的機制昔善,閏秒是為了將UTC時間和世界時(UT,下面會介紹世界時)對齊畔乙,確切的說是保證UTC和UT1(世界時的一種形式)相差不超過0.9s君仆。那么UTC和UT1為什么會出現(xiàn)差距呢?簡單說是因為二者對1s的計量方式不同,UTC采用的是原子時(TAI)的1秒(這也是當前對于1秒的標準定義)返咱,而UT1的1s和地球的自轉(zhuǎn)速度有關(guān)钥庇,觀測發(fā)現(xiàn),相對于原子時咖摹,地球的自轉(zhuǎn)速度是逐漸變慢的评姨,導致UT1會逐漸慢于UTC,因此UTC每隔一段時間(幾年)就要加1s等一等UT1萤晴,上一次閏秒就出現(xiàn)在2015年吐句,當時我們可以看到2015年6月30日23:59:60這樣的時間。

另外一個問題店读,為什么UTC一定要和UT1對齊呢嗦枢,直接使用UTC時間不就可以了?我認為两入,這是因為UTC是要服從于歷法的净宵,UTC仍舊是采用了年月日時分秒這樣的格式敲才,這顯然是歷法規(guī)定的格式裹纳,而太陽東升西落一次就是一天,四季輪回一次就是一年紧武,這是歷法的要求剃氧,也符合人類的認知習慣,UTC只是一套按照歷法的格式描述時間的標準而已阻星,不應當打破歷法本身朋鞍。因此,UTC引入了不太優(yōu)雅的閏秒機制來修正和歷法之間的沖突妥箕,當然也有一些聲音希望能有一套不需要閏秒的時間標準取代UTC滥酥,現(xiàn)在仍然存在著爭議。

上面提到了世界時(UT)和原子時(TAI)只需要簡單理解就可以畦幢,因為日常生活中我們不會直接使用到它們坎吻。世界時有多個形式,UT0宇葱、UT1等等瘦真,分別考慮了不同的因素,但他們最終的結(jié)果和UTC都相差不大黍瞧,我們只要知道世界時主要是和地球自轉(zhuǎn)相關(guān)的時間標準就可以了诸尽;而原子時(TAI)就是原子鐘定義的時間,實際上印颤,出于某些原因您机,原子時當前和UTC時間相差30多秒,所以我們?nèi)粘I钪懈惶赡苁褂玫剿?/p>

另外,不得不提的兩個時間是GMT(Greenwich Mean Time)和DST(daylight saving time)往产。

GMT時間和UTC時間很容易混淆被碗,二者從時間表示的結(jié)果上來看是一樣的,所以也經(jīng)撤麓澹看到UTC/GMT時間這樣的說法锐朴,但是二者其實是不一樣的概念。從歷史上來說蔼囊,UTC出現(xiàn)之前焚志,GMT時間就是世界標準時間,后來這個地位被UTC取代了畏鼓,GMT和UTC的差別主要在于酱酬,GMT實際上是指的一個時區(qū),而UTC是一套世界標準云矫,不指代任何時區(qū)膳沽,因此,我們可以討論英國當前是處在GMT時區(qū)還是BST時區(qū)让禀,卻不會說是處在UTC時區(qū)(參考:https://www.timeanddate.com/time/gmt-utc-time.html)挑社。但是在一般的理解上,把GMT和UTC時間看作相同的時間巡揍,也是沒什么問題的痛阻。

DST即夏令時,是一套相對比較復雜的時間標準腮敌,大體上是在夏季時撥快1小時的時鐘阱当,通過影響人的作息安排,以達到節(jié)省照明用電的目的糜工。我們之所以對夏令時比較陌生喻犁,是因為中國1992年之后就沒有再使用過夏令時了敌蜂,但是世界上仍然還有70多個國家在使用夏令時江滨,以歐洲和北美國家為主厦章。

另外我們經(jīng)常見到的一個時間是CST時間,比如我們在命令行中執(zhí)行date命令钮莲,可以看到

~ date
Mon Dec 28 23:21:19 CST 2020

CST一般表示的是中國標準時間(China Standard Time)免钻,是一個時區(qū)的縮寫,和GMT時區(qū)崔拥、BST時區(qū)等屬于同一類极舔,但是CST作為時區(qū)是存在歧義的,可以指代多個時區(qū)链瓦,美國中部時間拆魏、澳大利亞中部時間盯桦、古巴標準時間、中國的標準時間的縮寫都是CST渤刃。編寫代碼時用CST表示時區(qū)可能會引發(fā)錯誤拥峦,不建議使用。

上述歸納有作者個人理解卖子,如有問題歡迎指正略号。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市洋闽,隨后出現(xiàn)的幾起案子玄柠,更是在濱河造成了極大的恐慌,老刑警劉巖诫舅,帶你破解...
    沈念sama閱讀 222,681評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件羽利,死亡現(xiàn)場離奇詭異,居然都是意外死亡刊懈,警方通過查閱死者的電腦和手機这弧,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,205評論 3 399
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來虚汛,“玉大人匾浪,你說我怎么就攤上這事≡蠼” “怎么了户矢?”我有些...
    開封第一講書人閱讀 169,421評論 0 362
  • 文/不壞的土叔 我叫張陵玲献,是天一觀的道長殉疼。 經(jīng)常有香客問我,道長捌年,這世上最難降的妖魔是什么瓢娜? 我笑而不...
    開封第一講書人閱讀 60,114評論 1 300
  • 正文 為了忘掉前任,我火速辦了婚禮礼预,結(jié)果婚禮上眠砾,老公的妹妹穿的比我還像新娘。我一直安慰自己托酸,他們只是感情好褒颈,可當我...
    茶點故事閱讀 69,116評論 6 398
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著励堡,像睡著了一般谷丸。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上应结,一...
    開封第一講書人閱讀 52,713評論 1 312
  • 那天刨疼,我揣著相機與錄音泉唁,去河邊找鬼。 笑死揩慕,一個胖子當著我的面吹牛亭畜,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播迎卤,決...
    沈念sama閱讀 41,170評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼拴鸵,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了蜗搔?” 一聲冷哼從身側(cè)響起宝踪,我...
    開封第一講書人閱讀 40,116評論 0 277
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎碍扔,沒想到半個月后瘩燥,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 46,651評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡不同,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,714評論 3 342
  • 正文 我和宋清朗相戀三年厉膀,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片二拐。...
    茶點故事閱讀 40,865評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡服鹅,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出百新,到底是詐尸還是另有隱情企软,我是刑警寧澤,帶...
    沈念sama閱讀 36,527評論 5 351
  • 正文 年R本政府宣布饭望,位于F島的核電站仗哨,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏铅辞。R本人自食惡果不足惜厌漂,卻給世界環(huán)境...
    茶點故事閱讀 42,211評論 3 336
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望斟珊。 院中可真熱鬧苇倡,春花似錦、人聲如沸囤踩。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,699評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽堵漱。三九已至综慎,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間怔锌,已是汗流浹背寥粹。 一陣腳步聲響...
    開封第一講書人閱讀 33,814評論 1 274
  • 我被黑心中介騙來泰國打工变过, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人涝涤。 一個月前我還...
    沈念sama閱讀 49,299評論 3 379
  • 正文 我出身青樓媚狰,卻偏偏與公主長得像,于是被迫代替她去往敵國和親阔拳。 傳聞我的和親對象是個殘疾皇子崭孤,可洞房花燭夜當晚...
    茶點故事閱讀 45,870評論 2 361

推薦閱讀更多精彩內(nèi)容